Hi,
the following C++ code is indented as I expect:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
Asking TM2, I get it indented as:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
Christopher
Asking TM2, I get it indented as:
Confirm that. TM2 has very aggressive indentation handling. Which is very good, but it needs indention rules update for many languages, not only C++ but many (most) of the language bundles have similar problems.
It is best to have a look into the badly working indentation rules and try to fix it yourself then post the fix in the mailing list. I think this will be the quickest way to have things working for everybody, as I think Allan and Michael are very busy doing core updates.
Alternatively forking bundle from github.com/avian and asking to merge it back it good way to go.
Cheers,
On 24.01.12 16:27, Adam Strzelecki wrote:
It is best to have a look into the badly working indentation rules and try to fix it yourself then post the fix in the mailing list.
Basically, I agree. However, this looks to me like it requires either knowledge of TM2 I don't yet have or some additional support. Here's what I should have added to the first message already:
As far as I can see, this strange indenting is caused by the indentNextLinePattern matching all lines with an unterminated command. This causes each line to be indented relative to the preceding one. I don't know how to make all the lines indented relative to the one where the expression started, instead.
OTOH, as soon as indextNextLinePattern stops matching, we're back to the indenting of the line starting the whole thing. What is the intended meaning of indextNextLinePattern – indent relative to this line, or relative to whatever we'd otherwise use?
Christopher
On 24/01/2012, at 22.54, Christopher Creutzig wrote:
[…] OTOH, as soon as indextNextLinePattern stops matching, we're back to the indenting of the line starting the whole thing. What is the intended meaning of indextNextLinePattern – indent relative to this line, or relative to whatever we'd otherwise use?
The indentNextLine increase the indent relative to the current indent level.
This is kept in a register which is preserved if next line is also matched by the indentNextLine pattern.
An example where this makes sense would be:
if(true) while(false) for(size_t i = 0; i < 10; ++i) continue; return 0;
I don’t think TextMate 1.x is able to properly indent the above, but 2.0 will, even while you type it.
The downside of the line-based rule system is that breaking one statement across multiple lines is effectively unsupported, since each fragment is matched against the patterns and will thus be wrongly classified. I don’t know how this can be improved (other than do binary parsers for each language, but even that is quite a challenge for languages like C++).
On 2012-01-25 04:00, Allan Odgaard wrote:
An example where this makes sense would be:
if(true) while(false) for(size_t i = 0; i< 10; ++i) continue; return 0;
I don’t think TextMate 1.x is able to properly indent the above, but 2.0 will, even while you type it.
The downside of the line-based rule system is that breaking one statement across multiple lines is effectively unsupported, since each fragment is matched against the patterns and will thus be wrongly classified. I don’t know how this can be improved (other than do binary parsers for each language, but even that is quite a challenge for languages like C++).
If it's a choice between supporting code like your example or supporting a single statement split across lines, I say focus on the multi-line statement. Anyone who writes deeply nested C (or C-like) code without braces needs to be whacked upside the head with a cluestick, not encouraged by their editor.
In fact, I'd pay ten times as much if TextMate could be made to deliver a high-voltage electric shock to anyone who tried writing such an abomination! Call it something catchy like InvisibleCodeFence and you'll sell a million copies.
IMNSHO, of course. :-)
On 2012-01-31, at 4:38 pm, Steve King wrote:
On 2012-01-25 04:00, Allan Odgaard wrote:
An example where this makes sense would be:
if(true) while(false) for(size_t i = 0; i< 10; ++i) continue; return 0;
I don’t think TextMate 1.x is able to properly indent the above, but 2.0 will, even while you type it.
The downside of the line-based rule system is that breaking one statement across multiple lines is effectively unsupported, since each fragment is matched against the patterns and will thus be wrongly classified. I don’t know how this can be improved (other than do binary parsers for each language, but even that is quite a challenge for languages like C++).
If it's a choice between supporting code like your example or supporting a single statement split across lines, I say focus on the multi-line statement. Anyone who writes deeply nested C (or C-like) code without braces needs to be whacked upside the head with a cluestick, not encouraged by their editor.
In fact, I'd pay ten times as much if TextMate could be made to deliver a high-voltage electric shock to anyone who tried writing such an abomination! Call it something catchy like InvisibleCodeFence and you'll sell a million copies.
IMNSHO, of course. :-)
While it's cool that a language allows someone to write code like that - and I've done my fair share of it in the past, I would also hate to be the next guy who needs to debug or edit it especially if the indentations get fubar'd for whatever reason. Legibility rules especially once your prescription goes over -4 diopters.
Ed Wong
On 01/02/2012, at 04.38, Steve King wrote:
[…]
If it's a choice between supporting code like your example or supporting a single statement split across lines, I say focus on the multi-line statement. Anyone who writes deeply nested C (or C-like) code without braces needs to be whacked upside the head with a cluestick, not encouraged by their editor.
Well, the choice is more like, supporting well-defined nesting following (somewhat) deterministic rules that can be expressed via TextMate’s system versus adding a full C++ parser and a zillion options about preferences about how multi-line statements should be split, indented, and aligned ;)
In fact, I'd pay ten times as much if TextMate could be made to deliver a high-voltage electric shock to anyone who tried writing such an abomination!
The code example I gave may arise as a temporary state before having added braces, after removing some, or similar.
I'd prefer the second one (the one TM2 is using)...
just my 2 ct.
Am 24.01.2012 um 16:14 schrieb Christopher Creutzig:
Hi,
the following C++ code is indented as I expect:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
Asking TM2, I get it indented as:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
Christopher
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 24.01.12 16:56, Patric Zimmermann wrote:
Am 24.01.2012 um 16:14 schrieb Christopher Creutzig:
Hi,
the following C++ code is indented as I expect:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
Asking TM2, I get it indented as:
std::cerr << "a=" << a << ", b=" << b << ", c=" << c << std::endl;
I'd prefer the second one (the one TM2 is using)...
just my 2 ct.
Not trying to shoot your opinion down or anything, but I'm curious: Why? The meaning of the line, say, with the c, does not change at all when the lines for a and b above it are removed. Do you also prefer TM2's current indenting in this almost identical example?
f(1, 2, 3, 4, 5, 6);
Christopher
-
Adam Strzelecki -
Allan Odgaard -
Christopher Creutzig -
Ed Wong -
Patric Zimmermann -
Steve King