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.