GNU bug report logs - #77224
[PATCH] New minor mode 'cursor-indicators-mode'

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77224 <at> debbugs.gnu.org, eg642616 <at> gmail.com, juri <at> linkov.net
Subject: bug#77224: [PATCH] New minor mode 'cursor-indicators-mode'
Date: Sat, 29 Mar 2025 10:18:37 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: eg642616 <at> gmail.com,  77224 <at> debbugs.gnu.org,  juri <at> linkov.net
>> Date: Sat, 29 Mar 2025 09:32:09 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> >> Cc: eg642616 <at> gmail.com,  77224 <at> debbugs.gnu.org,  juri <at> linkov.net
>> >> Date: Sat, 29 Mar 2025 08:52:09 +0100
>> >> 
>> >> The `hl-line-highlight' moves the line highlight overlay, such that it
>> >> moves immediately with the cursor and does not lag behind.
>> >
>> > You may not be aware, but moving and changing overlays disables some
>> > redisplay optimizations, and in many cases can trigger an additional
>> > immediate redisplay cycle.  So doing that after every command exits
>> > in practice means every redisplay cycle is adversely affected.
>> 
>> I am aware. What do you suggest as an alternative? It would look odd if
>> the `hl-line-overlay' would not move directly with the cursor and would
>> lag behind.
>
> I could suggest one or two alternatives, but is it worth our time?  is
> someone actually considering any such changes?

Please do. I would like to understand your ideas.

> My point was and remains the same: adding more and more features to
> post-command-hook is something to be avoided.

Your argument from above does not matter in the case of `cursor-type'.
Since most commands do not trigger a modification of the `cursor-type',
the only cost that gets added to the `post-command-hooks' is the
inexpensive check of a few variables or conditions, which will not
affect redisplay.

I still do not understand why you are so strongly against a
`post-command-hook' in this case. I see that you are out of principle
against `post-command-hooks'. This makes sense given that these hooks
can be abused easily.

However in certain scenarios, after careful consideration, they might be
acceptable. As Juri mentioned, a `post-command-hook' allows us to
reliably change the `cursor-type' based on arbitrary conditions. In
contrast, if we use multiple hooks, which are registered in multiple
different subsystems, it is easy to miss relevant state changes.

Daniel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.