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(a)textmate.org> To: Peter Rando <peter.rando(a)yahoo.com>om>; TextMate users <textmate(a)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(a)yahoo.com> wrote: This style can’t be expressed with the current classification patterns. The best approximation is probably to remove { and } from the default patterns. 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: No, I don’t recall there having been made any changes to support https://en.wikipedia.org/wiki/Indentation_style#Whitesmiths_style 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`.