Highlight enclosing indentation?

[gekoke]

Is there any way to highlight the currently enclosing indentation (i.e., one level of indentation above the current one)?

This is the current behavior with indent-bars-highlight-current-depth set to t:

In this case, I'd like the first bar to be highlighted - not the second.

In this case, I'd like the second bar to be highlighted - not the third. In fact, I'd prefer for the last bar to not be render at all.

I understand that indent-bars-highlight-current-depth is named quite literally. I would find it much more useful if there was a indent-bars-highlight-enclosing-depth provided or similar. I was quite surprised when I realized that that's not what the former variable does, since this seems to be standard behavior in other editing environments.

[gekoke]

I suppose this is two separate issues: the ability to highlight enclosing space, and the ability to disable rendering of stipples for the last (non-enclosing) level of indentation.

[jdtsmith]

Sorry, you want to configure an arbitrary (likely negative) offset from the current indentation depth to actually highlight? The last bar won't be shown if the lines are filled. This uses a line-by-line-algorithm. If your innermost line were a for ...: wouldn't you want those bars?

Have you tried disabling display-on-blank-lines?

[gekoke]

Hi, thanks for your reply!

Have you tried disabling display-on-blank-lines?

I tried toggling the variable, but it doesn't seem like it's relevant (I will set it to nil for the sake of clarity henceforth, though).

I think what I mean would best be explained by the following example:

Given the following configuration:

(use-package indent-bars ;; at 230e3c8
  :hook
  (prog-mode . indent-bars-mode)
  (conf-mode . indent-bars-mode)
  (json-ts-mode . indent-bars-mode)
  :custom
  (indent-bars-display-on-blank-lines nil)
  (indent-bars-color '(highlight :face-bg t :blend 0.3))
  (indent-bars-pattern ".")
  (indent-bars-width-frac 0.1)
  (indent-bars-pad-frac 0.1)
  (indent-bars-highlight-current-depth '(:blend 1 :width 0.3)))

And given this file:

class Foo:
    @property
    def bars(self) -> Iterable[Bar]:
        entries = FooBar.objects.filter(foo=self)
        bars = [Bar(entry.bar) for entry in entries]
        return bars

    @property
    def bar_labels(self) -> Iterable[str]:
        return [bar.label for bar in self.bars]

    def add_bar(self, baz: Bar, quantity: int = 1):
        for __ in range(quantity):
            entry = FooBar()
            entry.foo = self
            entry.bar = baz
            entry.save()

indent-bars highlights the following bar:

And VSCode highlights the following bar, with the cursor at the same point (note the slightly brighter bar at line 10):

The latter is the behavior I would like and that I consider unsurprising.

[jdtsmith]

I tried toggling the variable, but it doesn't seem like it's relevant (I will set it to nil for the sake of clarity henceforth, though).

Did you also M-x indent-bars-reset after you altered it that variable? It's relevant to your statement I'd prefer for the last bar to not be render at all.

The latter is the behavior I would like and that I consider unsurprising.

What happens if you move that VSCode cursor forward between its current position, up to the return statement? indent-bars bases its "current highlight" on the indent of the current line, not the cursor position (which sounds quite distracting to me if that's what VSCode really does, since it will change as you move around the line).

[gekoke]

Did you also M-x indent-bars-reset after you altered it that variable? It's relevant to your statement I'd prefer for the last bar to not be render at all.

Yes, I did. I honestly had forgotten that I even mentioned it. That does disable rendering of the last bar, so we're all clear on that.

What happens if you move that VSCode cursor forward between its current position, up to the return statement? indent-bars bases its "current highlight" on the indent of the current line, not the cursor position (which sounds quite distracting to me if that's what VSCode really does, since it will change as you move around the line).

I didn't manage to capture the cursor on the screenshot, but it's actually at (just before) the return keyword on line 10, in the same position as it is in the screenshot with Emacs.

I've attached a video of VSCode's behavior.

https://github.com/jdtsmith/indent-bars/assets/63151928/ead26907-3e29-4f80-ba17-361f04a85dfb

Thanks for your time!

[jdtsmith]

Thanks, but it's very hard to follow the video or appreciate the differences. This is not just "enclosing scope". For example, when cursor is on the for __ in line, the highlighted bar is the one below it (just as in indent-bars).

I think your request is related to #24: constraining highlighting to stay within the local scope. This is technically challenging given the highlight mechanism used.

I do actually have some capability for that coming soon, so please check again when that becomes available (assuming you use treesitter and are interested).

[gekoke]

Thanks, but it's very hard to follow the video or appreciate the differences. This is not just "enclosing scope". For example, when cursor is on the for __ in line, the highlighted bar is the one below it (just as in indent-bars).

I think your request is related to #24: constraining highlighting to stay within the local scope. This is technically challenging given the highlight mechanism used.

Yes, I saw this issue. I specifically am not referring to this, though I understand that might not be clear since VSCode does support this.

I'm referring to the discrepancy in the bar chosen to highlight in the following situation - note that the cursor is at the same point in both images:

indent-bars highlights the following bar:

And VSCode highlights the following bar, with the cursor at the same point (note the slightly brighter bar at line 10):

Essentially, I'd expect the bar under def to be highlighted (the same behaviour as VSCode), not the one under the for.

Apologies, for the back and forth - I hope I'm not coming across as demanding, just having trouble finding the words to express what I mean clearly.

[jdtsmith]

If I added an option to highlight "one bar up" from what is current done, you would not like that either. Please read carefully my statement about the for __ in line; that proves quite clearly that multi-line syntax (and not just line-by-line indentation) is being used by VSCode to decide which bar to highlight. On the for __ in line, "one bar up" semantics would highlight the bar under all the def's, again differing from VSCode.

I think that you are so used to VSCode syntax-aware highlighting, you don't even realize that that's what it is doing. It seems "natural" to constrain highlighting to the surrounding syntactic scope (block, function, etc.), but doing so absolutely does require the type of thing #24 is asking for.

If you want to try simple "one bar up" semantics, you could evaluate the following quick advice in *scratch* (though beware, this is an internal function which could change):

(advice-add 'indent-bars--current-indentation-depth :filter-return
            (lambda (d) (max 0 (1- d))))

My guess is you will find (different) things about this you don't like.

[gekoke]

On the for __ in line, "one bar up" semantics would highlight the bar under def, again differing from VSCode.

I would find that acceptable

Not just one of the bars under a def, all of them; give it a try and let me know your thoughts. I might consider an update to make this an option, but I suspect you'll prefer the new tree-sitter syntax-aware version, assuming I can get it working well enough.

[gekoke]

With the limited testing I have done, I much prefer the highlighting of the indentation level just above the current one - I think it's far more natural and unsurprising.

Yes, the tree-sitter integration does sound promising.

[jdtsmith]

Interesting. I will probably make that an option at some point. Might even be a better default for TS (since with it, highlight is "contained" by the surrounding scope).

[jdtsmith]

The newly released v0.5 now includes tree-sitter based "scope" support, with full styling of the in-scope and out-of-scope bar regions. In addition, current highlight depth offers 3 methods, including the new default (context) which works well for me, and I think you'll prefer. Give a try and let me know of any issues.