Typically, from an empty file:

/**  * @file ns_gcov.c  */      ^

Another issue that seems to be related to the Doxygen/Javadoc comment block:

/** * @file foo.c */

void foo()

Hitting "{" on the last line will produce a one-column indentation:

/** * @file foo.c */

void foo() { }

Cheers, Manu

Allan:

I've been thinking about how to get around this problem, and I keep coming up with the same thing and then not bothering to post it here. I'm going to concentrate mainly on C/C++ here, but I think it will adapt to other languages too. Here goes:

Can we do something with scopes and indentation rules? I.e. if there is a multi line statement, then a scope attribute is set preventing the indentation rule from being applied again to subsequent lines. When a ; or some other "end of statement" pattern is received, then the attribute is removed, and indentation reduced on the next line. For this to work properly, the indentation rules would have to be specific to certain scopes.

cout << something // new line, and no semicolon - start of multiline statement, next line is indented << something_else // attr.multi-line is set, rule doesn't fire again << something_else; // semicolon clears the attribute

cout << done;

The indentation rules are then constructed using a language grammar rule for the start/end of multiline statements - which should be quite easy to write down in most cases. The start/end points of the rules could be a problem though. If we were to place the cursor after the first "something" (example above) and hit return, then we'd want it to indent as it would be "the first indent" in the multiline statement (ignoring the comments of course!). Thus the "don't indent the next line" scope needs to start after the \n.

Forcing a "shift-left" after the ; or "end pattern" will behave as the current rules do and recognise a ; (or other ending pattern) which is inside the multi-line statement scope.

Again, thinking of the C/C++ bundles, special statements like if, while, for which don't use braces can be left to indent on the next line as usual (i.e. the rule would not match a lack of ";", but rather "if ( .* )"

if (something) if (something else) // do something

I'm not sure if this is helpful - or even possible (I'm guessing you've thought about this a lot more than I have, and are likely to come up with something that's more practical to implement!).

Cheers,

Dave.

Hi Allan,

Which is exactly the case I linked to http://lists.macromates.com/textmate/2012-January/034269.html

Sure, I was just quoting it in my previous message.

The leading comment before #include is also known — the issue here is that includes are ignored for the purpose of indent, so it uses the level above the includes, and multi-line comments are messing this up.

Ok. So is there some known workaround until it gets fixed, except disabling the whole indentation feature altogether? If I understand it right, as soon as a Doxygen comment is introduced in a C file, there may be some issues with the following indentation. As all my functions are doxy-commented, I'm in trouble ;-)

By "workaround", I mean something like "ignore all comments for computing indentation level", and/or a special key sequence that could tell TM2 to cancel and not re-attempt the last indentation action.

Thanks, Manu

Hi Allan,

...

By "workaround", I mean something like "ignore all comments for computing indentation level",

The manual has a section about how these rules work. There are no hidden settings left out.

Ok, so I should read the manual to understand how to fix my indentation issues.

...

and/or a special key sequence that could tell TM2 to cancel and not re-attempt the last indentation action.

2.0 only makes indent corrections if the line prior to your edit was indented according to the patterns, and after the edit, is not. So if you change the indent once, it should stick.

If I understand it right, TM1 did not attempt to perform indent corrections *after* editing, whereas TM2 does; this may be the reason why I'm in trouble as long as I do not configure the indentation rules to fit ours. Time to read the documentation…

Thanks for your help, Manu.

On 01/03/2012, at 18.13, Emmanuel Blot wrote:

About the indentation rules:

• can they be edited from the TM2 bundle editor? It does not look

like the changes are taken into account, maybe there's a "refresh" or "reload" action to invoke?

You hit ⌘S after making changes, that should reload them automatically. You can always relaunch TextMate (⌃⌘Q) if you want to be sure that all caches are flushed, for indent patterns though I don’t believe there are any caching going on.

• they are reverted to the original settings once TM2 is restarted.

In the bundle editor? That indicates they were not saved on disk. Though normally you should get a warning if closing bundle editor with unsaved changes.

Should I copy them into my user directory so that they override the default ones?

No… perhaps you can give a step-by-step of how exactly you edited the patterns?