Re: highlight-indent-guides in display engine

[Ergus <spacibba@aol.com>]

On Sun, Jul 07, 2019 at 06:04:10PM +0300, Eli Zaretskii wrote:
>> Date: Sat, 6 Jul 2019 23:17:16 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> This email is a question about the highlight-indent-guides because some
>> people find that functionality very useful (and it is very common in
>> ides/editors around).
>>
>> I am using the package with that name [1] but It affects performance a
>> lot. Specially scrolling and responsiveness in general. Even when
>> disabling the animations.
>>
>> So my question is in two parts:
>>
>> 1) Does emacs already provides a way to reproduce this functionality
>> that does not kill performance so much, even if we sacrifice some
>> functionality?
>
>Not that I know of.  But there are some alternatives mentioned in the
>README of that package -- aren't some of them faster?
>
>> 2) Does it make sense to implement it in the display engine as we did
>> with the fill-column-indicator?
>
Hi Eli:

Sorry for the delay, but I've been very busy. 

>Hard to answer this question because the requirements aren't clear.
>The description of highlight-indent-guides doesn't include any
>systematic explanations of what the package does, only some quite
>terse description of some options.  Do you want to have all of what
>that package does, or only part (and if the latter, which part)?
>
Actually I like simplicity, so I will only support the simplest possible
approach that affects performance as least as possible. I don't care to
sacrifice functionality. Actually if there is not an efficient way to
do this it is better no implement it at all. (In my opinion)


>In general, I see potential difficulties in making this entirely part
>of the display code, because what is displayed in the indentation of
>each line depends directly and indirectly on what happens in preceding
>lines.  This means, for example, that when the display engine is
>invoked to lay out a single line, it might need to look backwards,
>potentially very far backwards, to find indentation on previous lines,
>If I'm not missing something, and this is indeed so, then such
>searches will almost certainly slow down redisplay considerably.
>
>Maybe someone will have clever ideas for how to avoid this problem.
>
Actually I had something like:

  (defun my/whitespace-mode () "My whitespace mode."
	 (setq whitespace-style '(face tabs tab-mark trailing)
	       whitespace-display-mappings	'((tab-mark 9 [?\u2502 9] [?\u2502 9])))
	 (custom-set-faces '(whitespace-tab ((t (:foreground "#444444")))))
	 (whitespace-mode 1))

As a prog-mode hook and with it's obvious limitations it used to be
enough for me. It is actually the approach that most of the editors
around implement more or less.

The only extra consideration it needs are:
1) What to do when people indent with spaces instead of tabs.
2) And how to avoid the tabs to be highlighted when not in the
indentation. (beginning of the line)

But none of them seems to be unsolvable.

From the packages:

I specially I don't want the dynamic part of the package that changes
colors when moving the cursor. But this is a personal choice (and
obviously there  will appear people asking for it in a while)

As a background I should mention that some time ago I was asking for the
indent-with-tabs align-with-spaces functionality to work out of the box,
specially because this code used to work perfectly fine for me with that
(And because I strongly believe that indent-with-tabs align-with-spaces
is much better than what provides indent-tabs-mode by default, because
it already mixes tabs with spaces but in a way that always produces the
wrong effect when changing the editor tab-width ...)

>Alternatively, we could implement part of the feature in Lisp, and the
>other part in C.  For example, determining what indentation levels
>should be displayed on a given line could be a job of the Lisp part.
>But before we decide that this is a viable alternative, we should
>profile the current Lisp implementation and find out which of its
>parts are responsible for slowdown.  Then we could decide whether this
>or that reimplementation will make the feature significantly faster.
>
I totally agree, I don't thing it is possible to implement this
efficiently enough purely in the lisp side with all the checks it
does. Which in spite of useful and accurate seems to be a bit expensive
and unneeded in most of the cases.

So lets go for the simplest case:

Check if indenting with spaces or tabs && add the indicator for
those character (or every tab-width spaces) from the beginning of the line
until the first different character of the line. And that's it...

Maybe add an option to highlight tabs when using spaces to indent and
vice-versa but that's a minor detail I don't really care too much.

Usually the users don't need more.