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

Previous Next

Full log

Message #200 received at 77224 <at> debbugs.gnu.org (full text, mbox):

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

> 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 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.

One idea is to use an idle timer.  Another is to reimplement this in
the display engine (which tracks the cursor position as part of its
job).

> > 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.

I think I already said everything I could, and repetition will not
help.  So I will respectfully bow out of this discussion.

Previous Next

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