emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: highlight-indent-guides in display engine


From: Ergus
Subject: Re: highlight-indent-guides in display engine
Date: Thu, 11 Jul 2019 21:06:51 +0200
User-agent: NeoMutt/20180716

On Sun, Jul 07, 2019 at 06:04:10PM +0300, Eli Zaretskii wrote:
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?

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]