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, Sure, I was just quoting it in my previous message. 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, Ok, so I should read the manual to understand how to fix my indentation issues. 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: 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. 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. No… perhaps you can give a step-by-step of how exactly you edited the patterns?