Re: highlight-indent-guides in display engine

[Eli Zaretskii]

> Date: Sat, 6 Jul 2019 23:17:16 +0200
> From: Ergus <address@hidden>
> 
> 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?

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)?

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.

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.