First of all, thank you very much for the quick response.  It's obviously not what I wanted to hear, but appreciated.  And now I know it wasn't just me being stupid all this time!

I'm a little heartened to hear that this is something you're looking at now.  If there's any way I can help encourage you along these lines, let me know!  My first thought regarding your proposed solution is that it seems like helping the cases you can, even if not perfect, is a good thing.  And I may be missing something (?), but it seems like a register system like you're describing would be at least "more helpful" in virtually all cases, no?

I don't know that it matters, but FWIW, I'm new to the list, but a paid user since long ago...

________________________________ From: Allan Odgaard mailinglist@textmate.org To: Peter Rando peter.rando@yahoo.com; TextMate users textmate@lists.macromates.com Sent: Sunday, April 21, 2013 10:21 PM Subject: Re: [TxMt] Question about indentation

On Apr 22, 2013, at 3:21, Peter Rando peter.rando@yahoo.com wrote:

I've used Whitesmith bracing style for *decades*, and had it kinda-sorta working in TM 1.5.x, though not perfectly.  Now I've lost those old settings and for the life of me can't figure out how to get it even close in 2.0 […]

This style can’t be expressed with the current classification patterns.

The best approximation is probably to remove { and } from the default patterns.

Also, just as a general suggestion, it seems like it would be really helpful to have just a handful of "packaged" example indentation rules for the small handful of  common bracing styles, i.e. Allman, K&R, Whitesmith, maybe Gnu.

The default pattenrs are compatible with both Allman and K&R. Neither Whitesmith nor Gnu can really be expressed ATM.

I’ve been considering ways to improve the indentation system, an obvious improvement would be to drop the somewhat arcanely named classification patterns and instead use a register based system where a match can add/subtract to a register, where a register represents the indent of the current line, future lines, or a “carry register”.

However, the biggest problem with the indent system is hard-wrapped lines and lisp-like languages, so while the above might be a nice improvement, it’s not really solving the real issue.

On 19 Sep 2018, at 21:34, kruemelkeksfan wrote:

a)

Allan Odgaard wrote

...

This style can’t be expressed with the current classification patterns.

this has changed by now?

No, I don’t recall there having been made any changes to support https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style

b) Whitesmith-style can't be (roughly) expressed by just increasing indent after a line finishes with ')' instead of '{', '}' or ';' and decreasing it after a line with a lone '}'? It doesn't need to be 100% accurate, a crude approximation for not having to type every single indent would be good enough for me...

You can make it increase indent after `)` (or maybe just lines not ending with `;` or braces), but the decrease indent pattern includes current line, so that would fail.

There would also be an issue with single line `if`, `for`, and `while` statements.

With the above, you end up with patterns like this:

{ increaseIndentPattern = '(?x) (?! .* [;:{},] \s* # do not indent when line ends with ;, :, {, }, or comma ( // .* | /[*] .* [*]/ \s* )? $ # …account for potential trailing comment | @(public|private|protected) # do not indent after obj-c data access keywords ) . # the negative look-ahead above means we don’t care about what we match here '; decreaseIndentPattern = '(?x) (?=not)possible '; indentNextLinePattern = '(?x)^ (?=not)possible '; unIndentedLinePattern = '^\s*((/*|*/|//|template\b.*?>(?!(.*))|@protocol|@optional|@interface(?!.*{)|@implementation|@end).*)?$'; zeroIndentPattern = '^\s*#'; }

I just disabled `decreaseIndentPattern` and `indentNextLinePattern`, plus made `increaseIndentPattern` use the pattern from the previous `indentNextLinePattern` pattern.

Additionally you would have to edit the _Return Inside Empty Item_ snippet in the source bundle. This triggers when you press return with insertion point between two braces, i.e. `{‸}` — adding `- source.c` to the scope selector should disable that for C.

Still, you may see TextMate’s indent corrector sometimes changing the indent of the current line, because the patterns does not correctly express how source should be indented.

The latter can be disabled by setting `disableIndentCorrections = :true;` for `source.c`.