Add "indent error handled block" to indenter settings

[Vogel612]

We received a feature-request via mail:

Hi. I really like the Indenting function, but there's a feature I'd like.

I'd like to set my own text I want indented. For instance, I often indent the code within the "On Error" block like this:

On Error Resume Next
        ActiveSheet.ShowAllData
On Error GoTo 0

In Rubberduck I'd like to go to a field called "Indent Lines Beginning With:" and add "On Error Resume Next", then go to a field called "Outdent Lines Beginning With:" and add "On Error GoTo 0".

Thanks!

-- Shawn Wilson

[ThunderFrame]

I think @retailcoder has been itching to treat OERN as an indented block. It seems this is the only "block" that needs to be added. It would certainly be easier to just add this case, rather than having user-specified indentation syntax rules.

[retailcoder]

With AutoComplete having a setting (enabled by default) to treat OERN...OEG0 as a block (and thus applying default indent accordingly), the AC's indenting would be undone by Smart Indenter - we do need an indenter setting for that, and AC needs to use indenter settings to determine whether or not to indent OERN...OEG0 "block" bodies.

While they would definitely be flexible, I don't think allowing user-defined blocks in indenter settings would be useful though. I'd prefer adjusting the indenter and its settings as new unhandled block constructs show up... other than OERN I can't think of any unhandled blocks at the moment.

[comintern]

This would likely be a little trickier than it would seem at first glance. The main issue is that the indenter works under the assumption that the code is syntactically correct, so it doesn't really pay attention to whether or not a block of code is "terminated" at all. For example, if you're missing an End Ifstatement it will happily rip through to the end of the procedure with the extra indentation level.

That means this would require a fairly substantial architectural change in order to "read ahead' in the code to see if there was an OEG0 before the end of the function. It would also require code path analysis, because the next OEG0 encountered after an OEGN might not be the end of the "block" (looking at you, error handling as flow control people...).

Remember, On Error isn't like a try catch - it's a single line directive. This makes it much, much more likely that this would trash indentation than anything else. I.e.

On Error Resume Next
...
On Error Goto Foo
...
On Error Goto 0
...
On Error Resume Next
...
End Sub

Not sure what to do with that ^^^...