#1547 Highlight indentation guide

[Thomas Linder Puls]

I think it would be a nice feature if the indentation guide corresponding to the line you are a at was/is highlighted.

In the attached image I on "else" in indentation level 2 and the relevant lines are those (also on level 2) going upwards meeting "if" and downwards meeting "end if".

It is (of course) much more interesting when you are scrolling several pages away (without changing caret position) to find the match.

[Neil Hodgson]

How exactly do you want to augment SCI_SETHIGHLIGHTGUIDE?

[Thomas Linder Puls]

Well, SCI_HIGHLIGHTGUIDE is a bit strange in my mind . I would hope for something that was more automatic than that.

Looking at the graphics (not considering an algorithm to calculate it). The highlighting is decided by the line with the caret (no highlighting if there is a multiline selection).

If the surrounding lines have same indentation then the guide line that is closest to the text should be highlighted.

|    aaaaa
|    |  xxxxx
|    |  caret here
|    |  xxxxx
|    bbbbb

I.e. the guide from aaaaa to bbbbb should be highlighted.

If the surrounding lines are both indented more than the current line:

|    aaaaa
|    |  xxxxx
|    bbbbb caret here
|    |  xxxxx
|    ccccc

Then both surrounding guide lines should be highlighted, i.e. the one from aaaaa to bbbbb and the one from bbbbb to ccccc.

The tricky thing is when one side is indented more than the other (here "above" is indented more) :

|    aaaaa
|    |    xxxxx
|    |    bbbbb
|    |    |  xxxxx
|    |    ccccc caret here
|    |    xxxxx
|    ddddd

In this case there could be two choices. The one from bbbbb to ccccc or the one from aaaaa to ddddd.

Which if these to choose could be decided using different settings, and could optionally be overwritten dynamically like when using SCI_HIGHLIGHTGUIDE. But it would not need provide a guide number it could just say 'inner' (meaning bbbbb to ccccc) or 'outer' (meaning aaaaa to ddddd).

If ccccc is a closing brace then 'inner' would correspond to the brace guide, but if the closing brace is on the previous line then 'outer' seems a better choice.

[Thomas Linder Puls]

I realize that with languages like lisp you may have several parentheses on the same line with different scopes (which I assume is the reason for letting the programmer figure out which guide to highlight using SCI_HIGHLIGHTGUIDE). Though I have not really considered why this should not be possible to automate either,

[Neil Hodgson]

Indentation highlight policy gets decided by the application since there are different ways people may want this to work.

In your motivating example, I would prefer that only the else branch be highlighted but you also want the if branch highlighted as well. Another may not want minor internal structures highlighted but only the indentation line that connects a whole method or function.

[Thomas Linder Puls]

Maybe, but it is possible to support both. The controlling option could support a few default actions (just like there is already a few different ways to show guide lines). So if you are "happy" with one of the defaults then you are done just by setting an option.

But should you like to analyze the context or just have a preference that doesn't match one of the options then you can override the default using SCI_HIGHLIGHTGUIDE.

However, I cannot see how SCI_HIGHLIGHTGUIDE (in its current form) can support that you choose "above", "below", or "both" in the 'else' case.

Considering "else" the situation in a "brace" language like C++/C# the situation is like this:

if (...) {
    ...
} else {
    ...
}

Here the brace match may go upwards or downwards depending on the brace you match.

Anyway, as I see it you often need to locate the "if" that corresponds to an "else", because that is where the condition is located. People often write the negated condition (in words) in a comment in the beginning of the else part, because that is very important for the else part.

A final note is that I have chosen an "else" in that place, but my suggestion does not consider what is there ('else', catch, ')<', ...) . I do however think that since both sides are indented more than the current line then we are most likely internally in a construction that starts above the current line and ends below the current line.

Again setting a general option for the view (above, below, or both) that handles most cases in you language and then checking dynamically for those that don't fit and override the behavior using (a perhaps extended) SCI_HIGHLIGHTGUIDE for those cases, seems to combine simplicify with full flexibility.