GNU bug report logs -
#77224
[PATCH] New minor mode 'cursor-indicators-mode'
Previous Next
To reply to this bug, email your comments to 77224 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sun, 23 Mar 2025 22:59:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Elijah Gabe Pérez <eg642616 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 23 Mar 2025 22:59:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Based on Stefan Kangas comments, this minor mode mode changes the cursor
appearance to indicate overwrite mode or read-only buffers.
This is extracted from `cua-enable-cursor-indications'.
-------------------- Start of forwarded message --------------------
From: Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: Should 'cua-overwrite-cursor-color' be standalone?
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>, emacs-devel <at> gnu.org
Date: Sat, 22 Mar 2025 02:01:11 -0500 (1 day, 15 hours, 49 minutes ago)
Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
> I've noticed about this variable today, but
> Should not this option be part of =overwrite= instead =cua=?
> Or be a standalone minor-mode?
>
> IMO, I find this useful outside =cua=.
I think a standalone mode is probably best, because if you want the
cursor color changed for overwrite-mode, you might want it for
buffer-read-only too.
In other words, I'd do both of these:
cua-overwrite-cursor-color
cua-read-only-cursor-color
FWIW, I have this in my init file since forever:
(setq my/set-cursor-color-color "")
(setq my/set-cursor-color-buffer "")
(defun my/set-cursor-color-according-to-mode ()
"Change cursor color according to some minor modes."
;; set-cursor-color is somewhat costly, so we only call it when needed:
(let ((color
(if buffer-read-only "#8888FF"
(if overwrite-mode "#000000"
"#FF0000"))))
(unless (and
(string= color my/set-cursor-color-color)
(string= (buffer-name) my/set-cursor-color-buffer))
(set-cursor-color (setq my/set-cursor-color-color color))
(setq my/set-cursor-color-buffer (buffer-name)))))
(add-hook 'post-command-hook 'my/set-cursor-color-according-to-mode)
I picked it up on EmacsWiki years ago.
-------------------- End of forwarded message --------------------
[Message part 2 (text/html, inline)]
[0001-New-minor-mode-cursor-indicators-mode.patch (text/patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 24 Mar 2025 07:38:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> FWIW, I have this in my init file since forever:
>
> (setq my/set-cursor-color-color "")
> (setq my/set-cursor-color-buffer "")
> (defun my/set-cursor-color-according-to-mode ()
> "Change cursor color according to some minor modes."
> ;; set-cursor-color is somewhat costly, so we only call it when needed:
> (let ((color
> (if buffer-read-only "#8888FF"
> (if overwrite-mode "#000000"
> "#FF0000"))))
> (unless (and
> (string= color my/set-cursor-color-color)
> (string= (buffer-name) my/set-cursor-color-buffer))
> (set-cursor-color (setq my/set-cursor-color-color color))
> (setq my/set-cursor-color-buffer (buffer-name)))))
> (add-hook 'post-command-hook 'my/set-cursor-color-according-to-mode)
Cool. Will it be possible to replace these settings in my init file
with the new package?
#+begin_src emacs-lisp
(defun my-change-cursor (&rest _)
"Change cursor color and type depending on insertion mode and input method."
(set-cursor-color
(cond (repeat-in-progress "blue")
(current-input-method "red3")
(t "black")))
(setq-default cursor-type
(cond (overwrite-mode 'box)
(t 'bar))))
(add-hook 'post-command-hook 'my-change-cursor t)
;; Also update the cursor on the repeat timer events:
(add-function :after repeat-echo-function #'my-change-cursor)
#+end_src
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 24 Mar 2025 18:12:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>> FWIW, I have this in my init file since forever:
>> (setq my/set-cursor-color-color "")
>> (setq my/set-cursor-color-buffer "")
>> (defun my/set-cursor-color-according-to-mode ()
>> "Change cursor color according to some minor modes."
>> ;; set-cursor-color is somewhat costly, so we only call it when needed:
>> (let ((color
>> (if buffer-read-only "#8888FF"
>> (if overwrite-mode "#000000"
>> "#FF0000"))))
>> (unless (and
>> (string= color my/set-cursor-color-color)
>> (string= (buffer-name) my/set-cursor-color-buffer))
>> (set-cursor-color (setq my/set-cursor-color-color color))
>> (setq my/set-cursor-color-buffer (buffer-name)))))
>> (add-hook 'post-command-hook 'my/set-cursor-color-according-to-mode)
> Cool. Will it be possible to replace these settings in my init file
> with the new package?
> #+begin_src emacs-lisp
> (defun my-change-cursor (&rest _)
> "Change cursor color and type depending on insertion mode and input method."
> (set-cursor-color
> (cond (repeat-in-progress "blue")
> (current-input-method "red3")
> (t "black")))
> (setq-default cursor-type
> (cond (overwrite-mode 'box)
> (t 'bar))))
> (add-hook 'post-command-hook 'my-change-cursor t)
> ;; Also update the cursor on the repeat timer events:
> (add-function :after repeat-echo-function #'my-change-cursor)
> #+end_src
Sure, I've updated the patch for handle this.
[Message part 2 (text/html, inline)]
[0001-New-minor-mode-cursor-indicators-mode.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 24 Mar 2025 18:50:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ship Mints <shipmints <at> gmail.com> writes:
> I think you need to update your configuration to not use tabs in lisp code--your patch is filled with tabs.
> Standard elisp is this (see emacs/.dir-locals.el for other settings):
> (emacs-lisp-mode . ((indent-tabs-mode . nil) ...
Yeah, i forgot to untabify the whole file.
Sending fixed one.
[Message part 2 (text/html, inline)]
[0001-New-minor-mode-cursor-indicators-mode.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Tue, 25 Mar 2025 07:35:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> +*** New minor mode 'cursor-indicators-mode'
> +This mode changes cursor appearance (color and/or type) to indicate
> +different buffer states. This mode have cursor indicators for:
> +- Overwrite mode
> +- Read-only buffers
> +- Repeat mode
> +- Input method activation
What if users want to add more conditions?
Could you try to create only one defcustom that
contains a list of default conditions
plus a possible user-defined conditions.
For example:
#+begin_src emacs-lisp
(defcustom cursor-indicators nil
:type `(alist :key-type
(choice :tag "Condition"
(const :tag "Overwrite mode" overwrite)
(const :tag "Read-only mode" read-only)
(const :tag "Repeat mode" repeat-in-progress)
(const :tag "Activated input method" input-method)
(function :tag "Matcher function")) ;; User-defined condition
:value-type
(choice
(const :tag "None (do not change cursor)" nil)
(color :tag "Color")
(choice :tag "Type"
(const :tag "Filled box" box)
(const :tag "Vertical bar" bar)
(const :tag "Horizontal bar" hbar)
(const :tag "Hollow box" hollow))
(cons :tag "Color and Type"
(choice :tag "Type"
(const :tag "Filled box" box)
(const :tag "Vertical bar" bar)
(const :tag "Horizontal bar" hbar)
(const :tag "Hollow box" hollow))
(color :tag "Color")))))
#+end_src
Then I could replace:
#+begin_src emacs-lisp
(defun my-change-cursor (&rest _)
"Change cursor color and type depending on insertion mode and input method."
(set-cursor-color
(cond (repeat-in-progress "blue")
(current-input-method "red3")
(t "black")))
(setq-default cursor-type
(cond (overwrite-mode 'box)
(t 'bar))))
#+end_src
with just
#+begin_src emacs-lisp
(setopt cursor-indicators '((repeat-in-progress "blue")
(current-input-method "red3")
(overwrite-mode 'box)
(default 'bar)))
#+end_src
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Tue, 25 Mar 2025 07:54:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> +*** New minor mode 'cursor-indicators-mode'
>> +This mode changes cursor appearance (color and/or type) to indicate
>> +different buffer states. This mode have cursor indicators for:
>> +- Overwrite mode
>> +- Read-only buffers
>> +- Repeat mode
>> +- Input method activation
>
> What if users want to add more conditions?
> Could you try to create only one defcustom that
> contains a list of default conditions
> plus a possible user-defined conditions.
> For example:
>
> #+begin_src emacs-lisp
> (defcustom cursor-indicators nil
> :type `(alist :key-type
> (choice :tag "Condition"
> (const :tag "Overwrite mode" overwrite)
> (const :tag "Read-only mode" read-only)
> (const :tag "Repeat mode" repeat-in-progress)
> (const :tag "Activated input method" input-method)
> (function :tag "Matcher function")) ;; User-defined condition
> :value-type
> (choice
> (const :tag "None (do not change cursor)" nil)
> (color :tag "Color")
> (choice :tag "Type"
> (const :tag "Filled box" box)
> (const :tag "Vertical bar" bar)
> (const :tag "Horizontal bar" hbar)
> (const :tag "Hollow box" hollow))
> (cons :tag "Color and Type"
> (choice :tag "Type"
> (const :tag "Filled box" box)
> (const :tag "Vertical bar" bar)
> (const :tag "Horizontal bar" hbar)
> (const :tag "Hollow box" hollow))
> (color :tag "Color")))))
> #+end_src
>
>
> Then I could replace:
>
> #+begin_src emacs-lisp
> (defun my-change-cursor (&rest _)
> "Change cursor color and type depending on insertion mode and input method."
> (set-cursor-color
> (cond (repeat-in-progress "blue")
> (current-input-method "red3")
> (t "black")))
> (setq-default cursor-type
> (cond (overwrite-mode 'box)
> (t 'bar))))
> #+end_src
>
>
> with just
>
> #+begin_src emacs-lisp
> (setopt cursor-indicators '((repeat-in-progress "blue")
> (current-input-method "red3")
> (overwrite-mode 'box)
> (default 'bar)))
> #+end_src
I set the following hooks, which makes the cursor unobtrusive while I'm
selecting text (C-SPC then moving cursor). Could this also fit in the
above framework?
(deactivate-mark-hook . (lambda () (setq cursor-type t)))
(activate-mark-hook . (lambda () (setq cursor-type 'bar)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Tue, 25 Mar 2025 12:13:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> Cc: 77224 <at> debbugs.gnu.org, shipmints <at> gmail.com, Juri Linkov <juri <at> linkov.net>
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Mon, 24 Mar 2025 12:49:19 -0600
>
> Ship Mints <shipmints <at> gmail.com> writes:
>
> I think you need to update your configuration to not use tabs in lisp code–your patch is filled with tabs.
> Standard elisp is this (see emacs/.dir-locals.el for other settings):
> (emacs-lisp-mode . ((indent-tabs-mode . nil) …
>
> Yeah, i forgot to untabify the whole file.
Thanks.
> +(defcustom cursor-indicators-overwrite-indicator "red3"
Using literal color names might be problematic on terminals that don't
support enough colors, unless you are extra careful to select colors
that are supported everywhere. Alternatively, the default value could
be different for different numbers of supported colors.
Also, what happens if an Emacs session has both GUI frames (with lots
of colors) and TTY frames with a small number of colors -- does each
frame get its own color?
> + "Cursor indicator used when overwrite mode is set, if non-nil.
That "if non-nil" part can potentially confuse, because it isn't clear
whether it refers to the value of the variable or to "overwrite mode".
Better say this the other way around:
If non-nil, the cursor indication to use when overwrite mode is set.
(Note that I also slightly reworded the rest of this sentence, for
clarity.)
Suggest to make the same changes for other user options in this file.
> +(defcustom cursor-indicators-repeat-indicator "blue"
> + "Cursor indicator used when `repeat-in-progress' is non-nil.
repeat-in-progress is an obscure variable, which is also not visible
until repeat.el is loaded. Please reword this to be in user-level
terms, like "when a command is repeated due to `repeat-mode'" or
something similar.
Please also add the :version tag to each and every new defcustom.
> +(defcustom cursor-indicators-input-method-indicator "dark magenta"
> + "Cursor indicator used when input method is activated now.
^^^
What do you mean by "now"?
> +(define-minor-mode cursor-indicators-mode
> + "Change cursor type and/or face for indications.
"Change cursor type and/or face to indicate various minor modes."
> +When enabled, this mode changes the cursor appearance to indicate
> +overwrite mode or read-only buffers."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is not the full list of indications.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Wed, 26 Mar 2025 04:56:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've updated the patch following Juri suggestions.
Now all the conditions are inside a single =defcustom=.
I've added only basic colors that a basic TTY can support, and a
=Package-Requires= tag in case this package should also be included in
ELPA.
This version now can handle functions as conditions (lambdas and function
symbols).
[Message part 2 (text/html, inline)]
[0001-New-minor-mode-cursor-indicators-mode.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Wed, 26 Mar 2025 05:02:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Rudolf Schlatte <rudi <at> constantly.at> writes:
> Juri Linkov <juri <at> linkov.net> writes:
>>> +*** New minor mode 'cursor-indicators-mode'
>>> +This mode changes cursor appearance (color and/or type) to indicate
>>> +different buffer states. This mode have cursor indicators for:
>>> +- Overwrite mode
>>> +- Read-only buffers
>>> +- Repeat mode
>>> +- Input method activation
>> What if users want to add more conditions?
>> Could you try to create only one defcustom that
>> contains a list of default conditions
>> plus a possible user-defined conditions.
>> For example:
>> #+begin_src emacs-lisp
>> (defcustom cursor-indicators nil
>> :type `(alist :key-type
>> (choice :tag "Condition"
>> (const :tag "Overwrite mode" overwrite)
>> (const :tag "Read-only mode" read-only)
>> (const :tag "Repeat mode" repeat-in-progress)
>> (const :tag "Activated input method" input-method)
>> (function :tag "Matcher function")) ;; User-defined condition
>> :value-type
>> (choice
>> (const :tag "None (do not change cursor)" nil)
>> (color :tag "Color")
>> (choice :tag "Type"
>> (const :tag "Filled box" box)
>> (const :tag "Vertical bar" bar)
>> (const :tag "Horizontal bar" hbar)
>> (const :tag "Hollow box" hollow))
>> (cons :tag "Color and Type"
>> (choice :tag "Type"
>> (const :tag "Filled box" box)
>> (const :tag "Vertical bar" bar)
>> (const :tag "Horizontal bar" hbar)
>> (const :tag "Hollow box" hollow))
>> (color :tag "Color")))))
>> #+end_src
>> Then I could replace:
>> #+begin_src emacs-lisp
>> (defun my-change-cursor (&rest _)
>> "Change cursor color and type depending on insertion mode and input method."
>> (set-cursor-color
>> (cond (repeat-in-progress "blue")
>> (current-input-method "red3")
>> (t "black")))
>> (setq-default cursor-type
>> (cond (overwrite-mode 'box)
>> (t 'bar))))
>> #+end_src
>> with just
>> #+begin_src emacs-lisp
>> (setopt cursor-indicators '((repeat-in-progress "blue")
>> (current-input-method "red3")
>> (overwrite-mode 'box)
>> (default 'bar)))
>> #+end_src
> I set the following hooks, which makes the cursor unobtrusive while I'm
> selecting text (C-SPC then moving cursor). Could this also fit in the
> above framework?
> (deactivate-mark-hook . (lambda () (setq cursor-type t)))
> (activate-mark-hook . (lambda () (setq cursor-type 'bar)))
Yeah, you can set it as something like this.
#+begin_src elisp
(setopt cursor-indicators-conditions '((use-region-p . "purple")))
#+end_src
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Wed, 26 Mar 2025 08:17:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> I've updated the patch following Juri suggestions.
> Now all the conditions are inside a single defcustom.
Thanks! I tested that everything works nicely.
There is only one small problem for repeat-mode:
> + (add-hook 'post-command-hook #'cursor-indicators--update-indications)
It would be better to use a large value DEPTH for add-hook
to add the hook to the end. The problem is that repeat-mode
also uses the same hook 'post-command-hook'. So the cursor
indication hook should be called afterwards as the last hook.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Wed, 26 Mar 2025 12:51:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77224 <at> debbugs.gnu.org
> Date: Wed, 26 Mar 2025 09:58:06 +0200
>
> > I've updated the patch following Juri suggestions.
> > Now all the conditions are inside a single defcustom.
>
> Thanks! I tested that everything works nicely.
> There is only one small problem for repeat-mode:
>
> > + (add-hook 'post-command-hook #'cursor-indicators--update-indications)
>
> It would be better to use a large value DEPTH for add-hook
> to add the hook to the end. The problem is that repeat-mode
> also uses the same hook 'post-command-hook'. So the cursor
> indication hook should be called afterwards as the last hook.
Would it be better to use an idle timer instead? post-command-hook
tends to make Emacs sluggish.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 00:52:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77224 <at> debbugs.gnu.org
>> Date: Wed, 26 Mar 2025 09:58:06 +0200
>> > I've updated the patch following Juri suggestions.
>> > Now all the conditions are inside a single defcustom.
>> Thanks! I tested that everything works nicely.
>> There is only one small problem for repeat-mode:
>> > + (add-hook 'post-command-hook #'cursor-indicators--update-indications)
>> It would be better to use a large value DEPTH for add-hook
>> to add the hook to the end. The problem is that repeat-mode
>> also uses the same hook 'post-command-hook'. So the cursor
>> indication hook should be called afterwards as the last hook.
> Would it be better to use an idle timer instead? post-command-hook
> tends to make Emacs sluggish.
Yeah, that is that what worried me when i decided to use that hook.
I've fixed the patch to use only idle-timer instead.
[Message part 2 (text/html, inline)]
[0001-New-minor-mode-cursor-indicators-mode.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 02:53:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I forgot to update commit message properly.
Sending fixed patch.
[Message part 2 (text/html, inline)]
[0001-New-package-cursor-indicators-mode-Bug-77224.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 05:49:04 GMT)
Full text and
rfc822 format available.
Message #44 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Juri Linkov <juri <at> linkov.net>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77224 <at> debbugs.gnu.org
>>> Date: Wed, 26 Mar 2025 09:58:06 +0200
>
>>> > I've updated the patch following Juri suggestions.
>>> > Now all the conditions are inside a single defcustom.
>
>>> Thanks! I tested that everything works nicely.
>>> There is only one small problem for repeat-mode:
>
>>> > + (add-hook 'post-command-hook #'cursor-indicators--update-indications)
>
>>> It would be better to use a large value DEPTH for add-hook
>>> to add the hook to the end. The problem is that repeat-mode
>>> also uses the same hook 'post-command-hook'. So the cursor
>>> indication hook should be called afterwards as the last hook.
>
>> Would it be better to use an idle timer instead? post-command-hook
>> tends to make Emacs sluggish.
>
> Yeah, that is that what worried me when i decided to use that hook.
>
> I've fixed the patch to use only idle-timer instead.
The problem with the idle timer is that it might not run immediately.
However when the user changes the input method, overwrite mode or
similar, the users expects that the cursor reflects the change
immediately after the last key press and does not lag behind. Therefore
I think there is no alternative to the `post-command-hook'. It seems to
me that only a bunch of mode variables are checked and then
`cursor-type' is set. In CUA the cursor indicator is also updated in the
`post-command-hook'. So this should not be too costly?
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 08:39:04 GMT)
Full text and
rfc822 format available.
Message #47 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77224 <at> debbugs.gnu.org, Juri Linkov
> <juri <at> linkov.net>
> Date: Thu, 27 Mar 2025 06:48:15 +0100
>
> Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
>
> >> Would it be better to use an idle timer instead? post-command-hook
> >> tends to make Emacs sluggish.
> >
> > Yeah, that is that what worried me when i decided to use that hook.
> >
> > I've fixed the patch to use only idle-timer instead.
>
> The problem with the idle timer is that it might not run immediately.
That depends on the value of the SECS argument to run-with-idle-timer,
doesn't it.
> However when the user changes the input method, overwrite mode or
> similar, the users expects that the cursor reflects the change
> immediately after the last key press and does not lag behind. Therefore
> I think there is no alternative to the `post-command-hook'. It seems to
> me that only a bunch of mode variables are checked and then
> `cursor-type' is set. In CUA the cursor indicator is also updated in the
> `post-command-hook'. So this should not be too costly?
Sorry, I object to adding stuff to post-command-hook in these cases.
Emacs becomes very sluggish, and we should avoid that as much as we
can.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 09:43:04 GMT)
Full text and
rfc822 format available.
Message #50 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77224 <at> debbugs.gnu.org, Juri Linkov
>> <juri <at> linkov.net>
>> Date: Thu, 27 Mar 2025 06:48:15 +0100
>>
>> Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:
>>
>> >> Would it be better to use an idle timer instead? post-command-hook
>> >> tends to make Emacs sluggish.
>> >
>> > Yeah, that is that what worried me when i decided to use that hook.
>> >
>> > I've fixed the patch to use only idle-timer instead.
>>
>> The problem with the idle timer is that it might not run immediately.
>
> That depends on the value of the SECS argument to run-with-idle-timer,
> doesn't it.
No, there is no guarantee that the idle timer will run soon enough after
the given time if Emacs stays busy.
>> However when the user changes the input method, overwrite mode or
>> similar, the users expects that the cursor reflects the change
>> immediately after the last key press and does not lag behind. Therefore
>> I think there is no alternative to the `post-command-hook'. It seems to
>> me that only a bunch of mode variables are checked and then
>> `cursor-type' is set. In CUA the cursor indicator is also updated in the
>> `post-command-hook'. So this should not be too costly?
>
> Sorry, I object to adding stuff to post-command-hook in these cases.
> Emacs becomes very sluggish, and we should avoid that as much as we
> can.
I see your point about sluggishness and I am very careful myself to not
enable modes which add expensive computations to the
`post-command-hook'. Nevertheless in this case using the
`post-command-hook' is the right thing, such that the `cursor-type' is
changed effective immediately, as had been done before in CUA, see
`cua--post-command-handler-1'. The computation in this case is not
expensive.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 11:15:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 27 Mar 2025 10:42:21 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> The problem with the idle timer is that it might not run immediately.
> >
> > That depends on the value of the SECS argument to run-with-idle-timer,
> > doesn't it.
>
> No, there is no guarantee that the idle timer will run soon enough after
> the given time if Emacs stays busy.
If Emacs is busy, the post-command-hook will not run, either. When a
command exits, it return to the main loop, and unless the user types
something before that, Emacs then becomes "idle".
> > Sorry, I object to adding stuff to post-command-hook in these cases.
> > Emacs becomes very sluggish, and we should avoid that as much as we
> > can.
>
> I see your point about sluggishness and I am very careful myself to not
> enable modes which add expensive computations to the
> `post-command-hook'. Nevertheless in this case using the
> `post-command-hook' is the right thing, such that the `cursor-type' is
> changed effective immediately, as had been done before in CUA, see
> `cua--post-command-handler-1'. The computation in this case is not
> expensive.
I disagree that the cursor must change "immediately", in the rigorous
sense of that word. I think if it changes after 10 or 20 or 50
milliseconds, that's "immediately" for any practical purpose.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 11:42:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> Cc: 77224 <at> debbugs.gnu.org, eg642616 <at> gmail.com, juri <at> linkov.net
> Date: Thu, 27 Mar 2025 13:14:45 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > I see your point about sluggishness and I am very careful myself to not
> > enable modes which add expensive computations to the
> > `post-command-hook'. Nevertheless in this case using the
> > `post-command-hook' is the right thing, such that the `cursor-type' is
> > changed effective immediately, as had been done before in CUA, see
> > `cua--post-command-handler-1'. The computation in this case is not
> > expensive.
>
> I disagree that the cursor must change "immediately", in the rigorous
> sense of that word. I think if it changes after 10 or 20 or 50
> milliseconds, that's "immediately" for any practical purpose.
Btw, a possibly even better way is to modify the cursor looks from the
hooks of the relevant commands, like overwrite-mode. If some of them
don't have a hook, we could add a hook. This is better because it
doesn't unnecessarily "punish" Emacs anywhere else, only the commands
that could affect the cursor.
Does this make sense?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 14:54:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Btw, a possibly even better way is to modify the cursor looks from the
> hooks of the relevant commands, like overwrite-mode. If some of them
> don't have a hook, we could add a hook. This is better because it
> doesn't unnecessarily "punish" Emacs anywhere else, only the commands
> that could affect the cursor.
>
But what if user prefer using a lambda instead a function? For example for
a specific mode or action from a key binding package such as evil or meow,
also i don't know if buffer-read-only have a proper hook.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 15:46:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> > > I see your point about sluggishness and I am very careful myself to not
> > > enable modes which add expensive computations to the
> > > `post-command-hook'. Nevertheless in this case using the
> > > `post-command-hook' is the right thing, such that the `cursor-type' is
> > > changed effective immediately, as had been done before in CUA, see
> > > `cua--post-command-handler-1'. The computation in this case is not
> > > expensive.
> >
> > I disagree that the cursor must change "immediately", in the rigorous
> > sense of that word. I think if it changes after 10 or 20 or 50
> > milliseconds, that's "immediately" for any practical purpose.
>
> Btw, a possibly even better way is to modify the cursor looks from the
> hooks of the relevant commands, like overwrite-mode. If some of them
> don't have a hook, we could add a hook. This is better because it
> doesn't unnecessarily "punish" Emacs anywhere else, only the commands
> that could affect the cursor.
>
> Does this make sense?
It does make sense, to me.
However, FWIW (haven't read all of this thread):
Based on input from Juri and others many moon ago, library `cursor-chg.el' has used pre(post)-command-hook since 2006 to optionally change the cursor shape for overwrite/read-only, idleness, and/or use of an input method. Minor mode `change-cursor-mode' does all but the idleness, which is done by `curchg-toggle-cursor-when-idle'.
I agree with the general motivation not to overuse pre(post)-command-hook, but FWIW I haven't noticed any problems with the use made of it in this case.
https://www.emacswiki.org/emacs/ChangingCursorDynamically
https://www.emacswiki.org/emacs/download/cursor-chg.el
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 16:03:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Thu, 27 Mar 2025 08:53:25 -0600
> Cc: mail <at> daniel-mendler.de, 77224 <at> debbugs.gnu.org,
> Juri Linkov <juri <at> linkov.net>
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Btw, a possibly even better way is to modify the cursor looks from the
> hooks of the relevant commands, like overwrite-mode. If some of them
> don't have a hook, we could add a hook. This is better because it
> doesn't unnecessarily "punish" Emacs anywhere else, only the commands
> that could affect the cursor.
>
> But what if user prefer using a lambda instead a function? For example for a specific mode or action from a
> key binding package such as evil or meow
Sorry, I don't understand: what lambda? Aren't all the modes you want
to catch normal minor modes with a hook?
> also i don't know if buffer-read-only have a proper hook.
read-only-mode does have a hook.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 16:05:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Thu, 27 Mar 2025 10:42:21 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> The problem with the idle timer is that it might not run immediately.
>> >
>> > That depends on the value of the SECS argument to run-with-idle-timer,
>> > doesn't it.
>>
>> No, there is no guarantee that the idle timer will run soon enough after
>> the given time if Emacs stays busy.
>
> If Emacs is busy, the post-command-hook will not run, either. When a
> command exits, it return to the main loop, and unless the user types
> something before that, Emacs then becomes "idle".
There is a difference. When Emacs executes a command and hangs during
command execution it is expected that the cursor does not update
immediately. The cursor will however update after the command has
finished. The commands which we talk about regarding cursor changes are
usually executed quickly, like enabling some modes like `overwrite-mode'.
>> > Sorry, I object to adding stuff to post-command-hook in these cases.
>> > Emacs becomes very sluggish, and we should avoid that as much as we
>> > can.
>>
>> I see your point about sluggishness and I am very careful myself to not
>> enable modes which add expensive computations to the
>> `post-command-hook'. Nevertheless in this case using the
>> `post-command-hook' is the right thing, such that the `cursor-type' is
>> changed effective immediately, as had been done before in CUA, see
>> `cua--post-command-handler-1'. The computation in this case is not
>> expensive.
>
> I disagree that the cursor must change "immediately", in the rigorous
> sense of that word. I think if it changes after 10 or 20 or 50
> milliseconds, that's "immediately" for any practical purpose.
No, 50ms are not acceptable for the user if they except an immediate
response to a key press. I have seen bug reports to my packages where
people complained about latency in the range of 10 to 20ms.
The problem is also that idle timers are not bounded. If the user
continues on typing, Emacs won't become idle and the cursor can change
much later. This would look like a bug then.
Again - CUA also used a `post-command-hook'. Why not preserve this,
given that the mode is essentially extracted from CUA where it works
well? I see your point about using specialized hooks though (e.g.
`overwrite-mode-hook'), but this will make customization much more
difficult, and for some variables there might not be a hook.
Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
optional mode. If it increases sluggishness unnacceptably (which it
won't), users can turn it off.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 16:31:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 27 Mar 2025 17:04:09 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I disagree that the cursor must change "immediately", in the rigorous
> > sense of that word. I think if it changes after 10 or 20 or 50
> > milliseconds, that's "immediately" for any practical purpose.
>
> No, 50ms are not acceptable for the user if they except an immediate
> response to a key press.
50ms was just an example, and it is actually quite improbable to be
that large.
post-command-hook is run by the same loop that decides that Emacs is
idle and runs timers, so the difference in practice should be very
small if at all.
> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
> optional mode. If it increases sluggishness unnacceptably (which it
> won't), users can turn it off.
Experience shows that many users turn on a lot of features which rely
on post-command-hook, and then complain that Emacs is slow to respond.
Telling them to turn off features they like doesn't really work.
Anyway, I think making the cursor change from a mode hook is a better
solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 16:41:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Thu, 27 Mar 2025 17:04:09 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I disagree that the cursor must change "immediately", in the rigorous
>> > sense of that word. I think if it changes after 10 or 20 or 50
>> > milliseconds, that's "immediately" for any practical purpose.
>>
>> No, 50ms are not acceptable for the user if they except an immediate
>> response to a key press.
>
> 50ms was just an example, and it is actually quite improbable to be
> that large.
>
> post-command-hook is run by the same loop that decides that Emacs is
> idle and runs timers, so the difference in practice should be very
> small if at all.
The `post-command-hook' is guaranteed to run after a command while the
idle timer is delayed until no new events are in the queue. This is why
I argue that the delay can be too large, such that it will become
noticeable.
>> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
>> optional mode. If it increases sluggishness unnacceptably (which it
>> won't), users can turn it off.
>
> Experience shows that many users turn on a lot of features which rely
> on post-command-hook, and then complain that Emacs is slow to respond.
> Telling them to turn off features they like doesn't really work.
I agree that this is a problem. However in this case the PCH will not
cause problems, as has also been noted by Drew and as has been shown by
CUA over the years. In contrast the idle timer will cause problems. I am
actually looking forward to using `cursor-indicators-mode', but if it
operates with an idle timer, I don't think it will indicate the editing
status reliably enough.
> Anyway, I think making the cursor change from a mode hook is a better
> solution.
As has been mentioned, the problem is that not every scenario is covered
by hooks, while the PCH is a potentially universal solution which can
check arbitrary conditions. But if hooks work sufficiently well for most
scenarios, then why not.
I think Stefan and Juri should chime in with their experience about
this, since as I've seen, they both want to replace some custom cursor
code with the new mode in their configuration.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 16:57:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 27 Mar 2025 17:39:59 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > post-command-hook is run by the same loop that decides that Emacs is
> > idle and runs timers, so the difference in practice should be very
> > small if at all.
>
> The `post-command-hook' is guaranteed to run after a command while the
> idle timer is delayed until no new events are in the queue.
No, the idle time is run immediately if there's no input. Emacs
doesn't wait or delay the timer.
> > Anyway, I think making the cursor change from a mode hook is a better
> > solution.
>
> As has been mentioned, the problem is that not every scenario is covered
> by hooks, while the PCH is a potentially universal solution which can
> check arbitrary conditions. But if hooks work sufficiently well for most
> scenarios, then why not.
If there are cases that this indication supports but there's no mode
hook for them, let's discuss those cases one by one and see how to
solve them. I see overwrite-mode, read-only-mode, and input-method
activation, all of which have hooks, AFAIR.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 17:11:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Date: Thu, 27 Mar 2025 08:53:25 -0600
>> Cc: mail <at> daniel-mendler.de, 77224 <at> debbugs.gnu.org,
>> Juri Linkov <juri <at> linkov.net>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> Btw, a possibly even better way is to modify the cursor looks from the
>> hooks of the relevant commands, like overwrite-mode. If some of them
>> don't have a hook, we could add a hook. This is better because it
>> doesn't unnecessarily "punish" Emacs anywhere else, only the commands
>> that could affect the cursor.
>> But what if user prefer using a lambda instead a function? For example for a specific mode or action from a
>> key binding package such as evil or meow
> Sorry, I don't understand: what lambda? Aren't all the modes you want
> to catch normal minor modes with a hook?
Not only minor mode, also functions (function symbols or anonymous ones).
for example if user wants to change cursor appearance if a text at
current cursor position have an overlay or whatever, can do it
defining a function in their config:
#+begin_src elisp
(defun my/cursor-change ()
(string-prefix-p " *" (buffer-name)))
(setopt cursor-indicators-conditions `((my/cursor-change hollow "yellow")))
#+end_src
or
#+begin_src elisp
(setopt cursor-indicators-conditions `((,(lambda () (string-prefix-p " *" (buffer-name)))
hollow "yellow")))
#+end_src
The current code only check if symbol is a variable or a function
symbol (since minor modes also defines a variable with same minor
mode name) or a lambda, and it must return =non-nil=.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 17:47:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: mail <at> daniel-mendler.de, juri <at> linkov.net, 77224 <at> debbugs.gnu.org
> Date: Thu, 27 Mar 2025 11:10:06 -0600
>
> But what if user prefer using a lambda instead a function? For example for a specific mode or action
> from a
> key binding package such as evil or meow
>
> Sorry, I don't understand: what lambda? Aren't all the modes you want
> to catch normal minor modes with a hook?
>
> Not only minor mode, also functions (function symbols or anonymous ones).
> for example if user wants to change cursor appearance if a text at
> current cursor position have an overlay or whatever, can do it
> defining a function in their config:
>
> (defun my/cursor-change ()
> (string-prefix-p " *" (buffer-name)))
>
> (setopt cursor-indicators-conditions `((my/cursor-change hollow "yellow")))
>
> or
>
> (setopt cursor-indicators-conditions `((,(lambda () (string-prefix-p " *" (buffer-name)))
> hollow "yellow")))
We have buffer-list-update-hook and window-configuration-change-hook,
which I think should cover these.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 18:01:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> I think Stefan and Juri should chime in with their experience about
> this, since as I've seen, they both want to replace some custom cursor
> code with the new mode in their configuration.
I tried the patch with 'run-with-idle-timer',
and even the delay 0.1 is noticeable and causes
the feeling that Emacs became sluggish
and can't update the cursor immediately.
So I'd prefer to use 'post-command-hook' that updates
the cursor immediately. I already used this
for many years, and there were no problems.
As for adding more specific hooks, this is not simple to do
since the cursor color depends on the current buffer and
should be updated every time after switching to another buffer.
And even with adding it to the display-buffer hook
the complexity will explode.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 18:26:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org
> Date: Thu, 27 Mar 2025 19:45:56 +0200
>
> > I think Stefan and Juri should chime in with their experience about
> > this, since as I've seen, they both want to replace some custom cursor
> > code with the new mode in their configuration.
>
> I tried the patch with 'run-with-idle-timer',
> and even the delay 0.1 is noticeable and causes
> the feeling that Emacs became sluggish
> and can't update the cursor immediately.
What about the delay of zero?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 18:28:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Anyway, I think making the cursor change from a mode hook is a better
>> > solution.
>> As has been mentioned, the problem is that not every scenario is covered
>> by hooks, while the PCH is a potentially universal solution which can
>> check arbitrary conditions. But if hooks work sufficiently well for most
>> scenarios, then why not.
> If there are cases that this indication supports but there's no mode
> hook for them, let's discuss those cases one by one and see how to
> solve them. I see overwrite-mode, read-only-mode, and input-method
> activation, all of which have hooks, AFAIR.
But the problem with using hooks is that modes sometimes defines a
specific name for hook or use different hooks for that, for example
overwrite-mode only defines overwrite-mode-hook, however input-method
defines input-method-activate-hook and input-method-deactivate-hook or
mark/region have activate-mark-hook and deactivate-mark-hook.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 18:36:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>> I think Stefan and Juri should chime in with their experience about
>> this, since as I've seen, they both want to replace some custom cursor
>> code with the new mode in their configuration.
> I tried the patch with 'run-with-idle-timer',
> and even the delay 0.1 is noticeable and causes
> the feeling that Emacs became sluggish
> and can't update the cursor immediately.
I think with 0.005 is most that fine, it's not immediate but also not
too lazy IMO.
Anyways the user can change the delay to 0.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 19:14:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 77224 <at> debbugs.gnu.org (full text, mbox):
>> > I think Stefan and Juri should chime in with their experience about
>> > this, since as I've seen, they both want to replace some custom cursor
>> > code with the new mode in their configuration.
>>
>> I tried the patch with 'run-with-idle-timer',
>> and even the delay 0.1 is noticeable and causes
>> the feeling that Emacs became sluggish
>> and can't update the cursor immediately.
>
> What about the delay of zero?
Ok, will try zero for a while.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 19:26:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77224 <at> debbugs.gnu.org,
> juri <at> linkov.net
> Date: Thu, 27 Mar 2025 12:27:22 -0600
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Anyway, I think making the cursor change from a mode hook is a better
> solution.
>
> As has been mentioned, the problem is that not every scenario is covered
> by hooks, while the PCH is a potentially universal solution which can
> check arbitrary conditions. But if hooks work sufficiently well for most
> scenarios, then why not.
>
> If there are cases that this indication supports but there's no mode
> hook for them, let's discuss those cases one by one and see how to
> solve them. I see overwrite-mode, read-only-mode, and input-method
> activation, all of which have hooks, AFAIR.
>
> But the problem with using hooks is that modes sometimes defines a
> specific name for hook or use different hooks for that, for example
> overwrite-mode only defines overwrite-mode-hook, however input-method
> defines input-method-activate-hook and input-method-deactivate-hook or
> mark/region have activate-mark-hook and deactivate-mark-hook.
If there's a single hook, it is called both when turning the mode on
and when turning it off, so I'm not sure I see the problem.
Anyway, I think I'm done arguing. I'm quite sure you all understand
my opinions and suggestions; if you want to disregard them and use the
post-command-hook anyway, feel free, but don't be surprised if someone
then complains that Emacs became a tad slower: it's because of all
these features that take the easy way out and use post-command-hook,
and by that add yet another one of those small slowdowns, which add up
and up...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:18:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Thu, 27 Mar 2025 17:39:59 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > post-command-hook is run by the same loop that decides that Emacs is
>> > idle and runs timers, so the difference in practice should be very
>> > small if at all.
>>
>> The `post-command-hook' is guaranteed to run after a command while the
>> idle timer is delayed until no new events are in the queue.
>
> No, the idle time is run immediately if there's no input. Emacs
> doesn't wait or delay the timer.
We are saying the same thing here. Yes, if there is no input, the idle
timer will run immediately. But if the user continues typing and events
are in the queue, then the timer will not run for some time. A delay
also occurs when an asynchronous process runs and fills a buffer in the
background like the *compilation* buffer. Then the cursor update will
lag behind.
I am with you that one should not carelessly add `post-command-hooks'. I
use various modes which use `post-command-hooks', idle timers and
regular timers, each for their proper use case. For example
`post-command-hooks' lead to sluggishness if they were used for auto
completion, spell checking or help at point (like Eldoc). For such use
cases idle timers or regular timers are the better tool since they defer
the expensive computation of completion strings, talking to a language
server, completion backend or a spell checker.
Here we discuss changing only the color of the cursor, a much much less
complex operation. The `cursor-type' update and checking a few variables
to find the color is a cheap operation which will not lead to
sluggishness. If this were an expensive operation, I would look
elsewhere for places to optimize, but avoiding `post-command-hook' is
not the solution.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:33:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 77224 <at> debbugs.gnu.org (full text, mbox):
On 3/27/2025 4:41 AM, Eli Zaretskii wrote:
> Btw, a possibly even better way is to modify the cursor looks from the
> hooks of the relevant commands, like overwrite-mode. If some of them
> don't have a hook, we could add a hook. This is better because it
> doesn't unnecessarily "punish" Emacs anywhere else, only the commands
> that could affect the cursor.
>
> Does this make sense?
That makes sense to me, and is approximately what I have in my own
configuration to do the same sort of thing as this patch. I update the
cursor by adding a hook to 'after-change-major-mode-hook' and then
adding variable watchers for 'buffer-read-only' and 'overwrite-mode'.
That was the most-reliable method I could find at the time. If there
were appropriate hooks for read-only/overwrite, then I think that would
be the ideal solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:42:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 77224 <at> debbugs.gnu.org (full text, mbox):
On March 27, 2025 12:29:59 PM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Thu, 27 Mar 2025 17:04:09 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I disagree that the cursor must change "immediately", in the rigorous
>> > sense of that word. I think if it changes after 10 or 20 or 50
>> > milliseconds, that's "immediately" for any practical purpose.
>>
>> No, 50ms are not acceptable for the user if they except an immediate
>> response to a key press.
>
>50ms was just an example, and it is actually quite improbable to be
>that large.
>
>post-command-hook is run by the same loop that decides that Emacs is
>idle and runs timers, so the difference in practice should be very
>small if at all.
>
>> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
>> optional mode. If it increases sluggishness unnacceptably (which it
>> won't), users can turn it off.
>
>Experience shows that many users turn on a lot of features which rely
>on post-command-hook, and then complain that Emacs is slow to respond.
>Telling them to turn off features they like doesn't really work.
Nor does telling external package authors not to use post-command-hook. I think there are two worthwhile approaches: 1) time the entries in post-command-hook and alert users about slow ones, and 2) provide a "do something when X, Y, or Z changes" API that authors could use when they would otherwise put something on PCH and check X, Y, and Z internally. Internally, we could DTRT and omit running those hooks when the relevant conditions haven't changed.
For example, instead of putting something buffer and focus dependent in PCH or fiddling with buffer and window and frame hooks, you could write something like
(call-on-change (:buffer :window :focus) #'my-thing)
or something like that.
It's not that you can't do the equivalent by manually adding my-thing to the appropriate hooks directly, but the convenient one stop syntax might guide people away from PCH.
>
>Anyway, I think making the cursor change from a mode hook is a better
>solution.
+1
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:49:01 GMT)
Full text and
rfc822 format available.
Message #116 received at submit <at> debbugs.gnu.org (full text, mbox):
On March 27, 2025 4:41:39 PM EDT, Daniel Colascione <dancol <at> dancol.org> wrote:
>
>
>On March 27, 2025 12:29:59 PM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>>> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
>>> Date: Thu, 27 Mar 2025 17:04:09 +0100
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> > I disagree that the cursor must change "immediately", in the rigorous
>>> > sense of that word. I think if it changes after 10 or 20 or 50
>>> > milliseconds, that's "immediately" for any practical purpose.
>>>
>>> No, 50ms are not acceptable for the user if they except an immediate
>>> response to a key press.
>>
>>50ms was just an example, and it is actually quite improbable to be
>>that large.
>>
>>post-command-hook is run by the same loop that decides that Emacs is
>>idle and runs timers, so the difference in practice should be very
>>small if at all.
>>
>>> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
>>> optional mode. If it increases sluggishness unnacceptably (which it
>>> won't), users can turn it off.
>>
>>Experience shows that many users turn on a lot of features which rely
>>on post-command-hook, and then complain that Emacs is slow to respond.
>>Telling them to turn off features they like doesn't really work.
>
>Nor does telling external package authors not to use post-command-hook. I think there are two worthwhile approaches: 1) time the entries in post-command-hook and alert users about slow ones, and 2) provide a "do something when X, Y, or Z changes" API that authors could use when they would otherwise put something on PCH and check X, Y, and Z internally. Internally, we could DTRT and omit running those hooks when the relevant conditions haven't changed.
>
>For example, instead of putting something buffer and focus dependent in PCH or fiddling with buffer and window and frame hooks, you could write something like
>
>(call-on-change (:buffer :window :focus) #'my-thing)
>
>or something like that.
>
>It's not that you can't do the equivalent by manually adding my-thing to the appropriate hooks directly, but the convenient one stop syntax might guide people away from PCH.
Also, we'd be able to coalesce and debounce calls to these change functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 27 Mar 2025 20:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 00:50:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Would it be better to use an idle timer instead? post-command-hook
> tends to make Emacs sluggish.
post-command-hook is the most general, and thus the simplest way to
implement something like this, but not necessarily a good way. A
solution using such a general tool like post-command-hook also comes
with problems. What if something adds something to post-command-hook
that changes one of the conditions that should trigger a cursor type
change? And yes, obviously, the conditions are checked much too often
when using post-command-hook, and yes, people will complain because they
are will add conditions where checking is not that cheap.
Timers are a bit better, but are also far from optimal.
I would really prefer to use other hooks. If we miss a hook, let's add
those hooks we miss.
Nearly all uses of hooks could be replaced by adding something to
post-command-hook, but the other hooks are there for a reason. What's
different in this case that justifies this measure here (the question
does not go to Eli, obviously)?
If we can't use other hooks, are there other alternatives? Variable
watchers have been mentioned - would using those be possible? Or, could
we at least try to use the buffer local binding of post-command-hook, at
least for conditions that are buffer local anyway?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 06:50:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 27 Mar 2025 21:17:25 +0100
>
> Here we discuss changing only the color of the cursor, a much much less
> complex operation.
My point is that when the list on post-command-hook is long, it takes
Emacs time to process all the functions on the list, and the longer
the list, the less responsive Emacs will be. These small
insignificant delays add up.
How long is the post-command-hook list in your production sessions?
Should we poll users to give their data? Just yesterday someone
complained on Reddit that Emacs is too slow, and I have no doubt that
features that use post-command-hook are at least part of the reason if
not _the_ reason.
So I maintain that we should try to avoid post-command-hook for
operations that should happen very rarely (this case is one such case:
we only want to run this code when something is turned on or off).
Even if the reaction to the change is a bit slower, it is worth our
while to pay that price: users will be a tad happier with Emacs
response times. And if there are alternative methods of doing the
same, like the respective mode hooks in this case, we should use them
without thinking twice. Ideally, post-command-hook should only be
used for stuff that really must be done after almost every command;
for any other cases we should look for other Emacs features to do the
job.
Emacs is a very old program, and if we do it right, it will live a
long time since. We should realize the long-run effects of (ab)using
stuff like post-command-hook, and try to imagine how much more stuff
will be accrued in post-command-hook 40 years hence if we lower our
guards in this regard.
But I repeat myself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 07:08:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Daniel Colascione <dancol <at> dancol.org> writes:
>>Anyway, I think making the cursor change from a mode hook is a better
>>solution.
I've updated the patch which should use the mode hook instead using
=post-command-hook= or idle timers (and allows (implicitly) to user use
post-command-hook (but that is user responsibility add it or not)).
Also this should refresh the cursor while switching windows.
However I've deleted the function/lambdas support as conditions because
i found it problematic.
I've test it only for overwrite-mode, I ask if anyone wants to give it a try.
[Message part 2 (text/html, inline)]
[0001-New-package-cursor-indicators-mode-Bug-77224.patch (text/x-patch, attachment)]
[Message part 4 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 07:19:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 27 Mar 2025 16:41:39 -0400
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: 77224 <at> debbugs.gnu.org, eg642616 <at> gmail.com, juri <at> linkov.net
>
> >> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
> >> optional mode. If it increases sluggishness unnacceptably (which it
> >> won't), users can turn it off.
> >
> >Experience shows that many users turn on a lot of features which rely
> >on post-command-hook, and then complain that Emacs is slow to respond.
> >Telling them to turn off features they like doesn't really work.
>
> Nor does telling external package authors not to use post-command-hook.
Well, I could at least try ;-) Who knows, some of them might even
listen...
> I think there are two worthwhile approaches: 1) time the entries in post-command-hook and alert users about slow ones, and 2) provide a "do something when X, Y, or Z changes" API that authors could use when they would otherwise put something on PCH and check X, Y, and Z internally. Internally, we could DTRT and omit running those hooks when the relevant conditions haven't changed.
I'd be okay with developing 1), I think it's a good feature, given the
proliferation of features that use this hook.
As for 2), I think we already have that: add-variable-watcher. We
already use this for a small number of features. Does that fit the
bill?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 07:33:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data?
I use very many Emacs features, but my post-command-hook is just
(repeat-post-hook my-change-cursor)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 07:33:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> I've updated the patch which should use the mode hook instead using
> post-command-hook or idle timers (and allows (implicitly) to user use
> post-command-hook (but that is user responsibility add it or not)).
>
> Also this should refresh the cursor while switching windows.
>
> However I've deleted the function/lambdas support as conditions because
> i found it problematic.
>
> I've test it only for overwrite-mode, I ask if anyone wants to give it a
> try.
Please note that this is insufficient for 'repeat-mode'.
Currently it requires adding an advice to update the cursor
on the repeat timer events:
(add-function :after repeat-echo-function #'cursor-indicators--update-indications)
since need to update the cursor when the timer is fired:
(run-with-idle-timer timeout nil #'repeat-exit)
(defun repeat-exit ()
(setq repeat-in-progress nil)
(funcall repeat-echo-function nil))
This problem can be solved by adding a hook:
(defun repeat-exit ()
(setq repeat-in-progress nil)
(funcall repeat-echo-function nil)
(run-hooks 'repeat-exit-hook))
Then 'cursor-indicators-mode' needs to add this hook:
(define-minor-mode cursor-indicators-mode
...
(add-hook 'repeat-exit-hook #'cursor-indicators--update-indications)
Then maybe it's possible to add more hooks for other features as well.
The drawback of this approach is that specific hooks make the cursor updating
less reliable than with using post-command-hook.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 07:39:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Juri Linkov <juri <at> linkov.net>, 77224 <at> debbugs.gnu.org, eg642616 <at> gmail.com
> Date: Fri, 28 Mar 2025 01:51:03 +0100
>
> If we can't use other hooks, are there other alternatives? Variable
> watchers have been mentioned - would using those be possible?
Yes, if some change should be triggered by a variable, we can use
variable watchers. IMO, it would be better than either the idle timer
or post-command-hook.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 14:29:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 27 Mar 2025 16:41:39 -0400
>> From: Daniel Colascione <dancol <at> dancol.org>
>> CC: 77224 <at> debbugs.gnu.org, eg642616 <at> gmail.com, juri <at> linkov.net
>>
>> >> Regarding Emacs sluggishness, the `cursor-indicators-mode' is an
>> >> optional mode. If it increases sluggishness unnacceptably (which it
>> >> won't), users can turn it off.
>> >
>> >Experience shows that many users turn on a lot of features which rely
>> >on post-command-hook, and then complain that Emacs is slow to respond.
>> >Telling them to turn off features they like doesn't really work.
>>
>> Nor does telling external package authors not to use post-command-hook.
>
> Well, I could at least try ;-) Who knows, some of them might even
> listen...
>
>> I think there are two worthwhile approaches: 1) time the entries in
>> post-command-hook and alert users about slow ones, and 2) provide a
>> "do something when X, Y, or Z changes" API that authors could use
>> when they would otherwise put something on PCH and check X, Y, and Z
>> internally. Internally, we could DTRT and omit running those hooks
>> when the relevant conditions haven't changed.
>
> I'd be okay with developing 1), I think it's a good feature, given the
> proliferation of features that use this hook.
Yeah. SHTDI though, and I'm not going to be able to get to it soon.
> As for 2), I think we already have that: add-variable-watcher. We
> already use this for a small number of features. Does that fit the
> bill?
No, because variable watchers are synchronous --- also, they're hacky:
they let you run arbitrary code at nearly arbitrary points.
Like advice, they're a last resort and a debugging aid, and ISTM if
we're using them to implement features, something is wrong. I think
we're conditioned to understand that named functions can be advised, but
most people aren't thinking of arbitrary variable assignments as
extension points.
The feature I'm proposing is higher-level than that. For example, for
my personal use, I have something that sits in pre-redisplay-function
and scans all the windows for applying highlights based on current
buffer and window selection. I should have written this thing using the
appropriate window configuration change hooks, but didn't, because I'm
lazy and my approach is fast enough for me.
;; Don't do this.
(defun window-highlight--pre-redisplay (_window)
(window-highlight--rescan-windows))
(add-function :after pre-redisplay-function
#'window-highlight--pre-redisplay))
What I'd have wanted instead is something like this:
(run-when-changed
(list (selected-window) (selected-frame) (frame-focus-state))
#'window-highlight--rescan-windows)
Here, we'd run window-highlight--rescan-windows only when one of its
dependent conditions (e.g. selected frame) changed. After any number of
window and frame changes, we'd run window-highlight--rescan-windows
*once*, immediately before its effects would become user-visible
(e.g. just before redisplay, or after commands), and we wouldn't re-run
it until one of its preconditions changed.
It's certainly possible to do the same coalescing and change detection
manually, but it's inconvenient. It's easier to just throw something in
pre-redisplay or post-command-hook, so that's what people do.
Level-triggered control is easier to reason about than
edge-triggered control.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Thu, 27 Mar 2025 21:17:25 +0100
>>
>> Here we discuss changing only the color of the cursor, a much much less
>> complex operation.
>
> My point is that when the list on post-command-hook is long, it takes
> Emacs time to process all the functions on the list, and the longer
> the list, the less responsive Emacs will be. These small
> insignificant delays add up.
I see your point. But not only the length of the list but also the
weight of the specific hook functions matters. A handful of
insignificant delays add up, but will still stay insignificant. There
are not that many hooks installed in the PCH list (see my list below).
In the reports where users complain about slow Emacs, it seems more
likely that one bad hook outweighs all the others.
> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data? Just yesterday someone
> complained on Reddit that Emacs is too slow, and I have no doubt that
> features that use post-command-hook are at least part of the reason if
> not _the_ reason.
Indeed. PCHs are a common reason for slow down. Even worse are functions
which run during redisplay. Heavy custom mode lines seem to be the main
problem here.
My `post-command-hook' list looks like this:
Buffer-local:
(jit-lock--antiblink-post-command eldoc-schedule-timer
corfu--auto-post-command jinx--reschedule
whitespace-post-command-hook hl-line-highlight t)
Global:
(ibuffer-auto-update-changed repeat-post-hook)
I don't have any problems with these hooks, since they are either cheap
or only schedule some timers for more expensive operations. At least I
don't notice any sluggishness and the PCHs don't appear in profiles.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 16:03:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Mar 28, 2025 at 11:41 AM Daniel Mendler via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> 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: Thu, 27 Mar 2025 21:17:25 +0100
> >>
> >> Here we discuss changing only the color of the cursor, a much much less
> >> complex operation.
> >
> > My point is that when the list on post-command-hook is long, it takes
> > Emacs time to process all the functions on the list, and the longer
> > the list, the less responsive Emacs will be. These small
> > insignificant delays add up.
>
> I see your point. But not only the length of the list but also the
> weight of the specific hook functions matters. A handful of
> insignificant delays add up, but will still stay insignificant. There
> are not that many hooks installed in the PCH list (see my list below).
> In the reports where users complain about slow Emacs, it seems more
> likely that one bad hook outweighs all the others.
>
> > How long is the post-command-hook list in your production sessions?
> > Should we poll users to give their data? Just yesterday someone
> > complained on Reddit that Emacs is too slow, and I have no doubt that
> > features that use post-command-hook are at least part of the reason if
> > not _the_ reason.
>
> Indeed. PCHs are a common reason for slow down. Even worse are functions
> which run during redisplay. Heavy custom mode lines seem to be the main
> problem here.
>
> My `post-command-hook' list looks like this:
>
> Buffer-local:
> (jit-lock--antiblink-post-command eldoc-schedule-timer
> corfu--auto-post-command jinx--reschedule
> whitespace-post-command-hook hl-line-highlight t)
>
> Global:
> (ibuffer-auto-update-changed repeat-post-hook)
>
> I don't have any problems with these hooks, since they are either cheap
> or only schedule some timers for more expensive operations. At least I
> don't notice any sluggishness and the PCHs don't appear in profiles.
>
I have experienced issues in the past with PCH entries and cleaned it all
up ages ago and try to keep an eye on it. One culprit was the pyvenv
tracker which I rewrote a private copy of to use a different method that
achieves the same effect with less overhead.
Out of both curiosity and to butt in on this discussion, I posted this
casual survey on reddit
https://www.reddit.com/r/emacs/comments/1jlyek0/show_your_postcommandhook_contents_to_help_emacs/
Perhaps we'll see that the bulk of people's PCH is the usual
well-performing suspects. I posted mine.
-Stephane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 16:33:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Fri, 28 Mar 2025 16:40:29 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> My `post-command-hook' list looks like this:
>
> Buffer-local:
> (jit-lock--antiblink-post-command eldoc-schedule-timer
> corfu--auto-post-command jinx--reschedule
> whitespace-post-command-hook hl-line-highlight t)
And in Org buffers?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 16:50:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Fri, 28 Mar 2025 16:40:29 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> My `post-command-hook' list looks like this:
>>
>> Buffer-local:
>> (jit-lock--antiblink-post-command eldoc-schedule-timer
>> corfu--auto-post-command jinx--reschedule
>> whitespace-post-command-hook hl-line-highlight t)
>
> And in Org buffers?
The first list was from the *scratch* buffer. This one is from an Org
buffer:
(eldoc-schedule-timer corfu--auto-post-command jinx--reschedule
whitespace-post-command-hook hl-line-highlight t)
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 16:59:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data? Just yesterday someone
> complained on Reddit that Emacs is too slow, and I have no doubt that
> features that use post-command-hook are at least part of the reason if
> not _the_ reason.
Here is my post-command-hook in an Org mode buffer in Emacs 29:
(yas--post-command-handler
org-latex-preview-auto--handle-post-cursor
visible-mark-move-overlays
dot-mode-loop
corfu--auto-post-command
t)
That's the buffer-local value. In addition, the global value is:
(global-font-lock-mode-check-buffers
global-eldoc-mode-check-buffers
global-prettify-symbols-mode-check-buffers
magit-auto-revert-mode-check-buffers
c-post-command
repeat-post-hook
mode-local-post-major-mode-change)
-----
And here are the minor modes I'm using that are installing these hooks.
Modes from packages I've installed explicitly:
- org-latex-preview-auto-mode: Detects and previews LaTeX fragments in
Org buffers as they are typed. (I authored this mode, it is designed
to be as nonintrusive as possible.)
- yas-minor-mode: for Yasnippets (template expansion)
- visible-mark-mode: Highlights the position of the usually invisible
mark.
- dot-mode: Vim-style repeat operator for text insertion.
- corfu-mode: Autocompletion as you type.
The following modes are from built-in Emacs packages:
- font-lock-mode
- global-eldoc-mode
- global-prettify-symbols-mode
- repeat-mode
Of the remaining, I use Magit with its default settings, under which it
installs `magit-auto-revert-mode-check-buffers'.
I don't know why `c-post-command' is in the global post-command-hook. I
haven't even edited any C files in this Emacs session.
I don't know why `mode-local-post-major-mode-change' is installed either.
------
Although my Emacs isn't so slow that I can't type comfortably, I can
definitely perceive some difference between Emacs' responsiveness with the
above settings and `emacs -q'.
I would very much like some of these to be moved into different hooks
that trigger only when required. Daniel's idea for something like this:
(call-on-change (:buffer :window :focus) #'my-thing)
would be very useful.
> So I maintain that we should try to avoid post-command-hook for
> operations that should happen very rarely (this case is one such case:
> we only want to run this code when something is turned on or off).
> Even if the reaction to the change is a bit slower, it is worth our
> while to pay that price: users will be a tad happier with Emacs
> response times. And if there are alternative methods of doing the
> same, like the respective mode hooks in this case, we should use them
> without thinking twice. Ideally, post-command-hook should only be
> used for stuff that really must be done after almost every command;
> for any other cases we should look for other Emacs features to do the
> job.
For this reason I try quite hard to avoid using post-command-hook in my
packages.
Karthik
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 28 Mar 2025 21:14:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 28, 2025, at 3:30 AM, Juri Linkov <juri <at> linkov.net> wrote:
>
> Please note that this is insufficient for 'repeat-mode'.
> Currently it requires adding an advice to update the cursor
> on the repeat timer events:
I solved this problem by wrapping the `repeat-echo-function' and `after-focus-change-function'.
https://gist.github.com/jdtsmith/a169362879388bc1bdf2bbb977782d4f
Emacs: change cursor color during active repeat-mode commands
gist.github.com
[Message part 2 (text/html, inline)]
[gist-og-image-54fd7dc0713e.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 00:41:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Daniel Colascione <dancol <at> dancol.org> writes:
> The feature I'm proposing is higher-level than that. For example, for
> my personal use, I have something that sits in pre-redisplay-function
> and scans all the windows for applying highlights based on current
> buffer and window selection. I should have written this thing using the
> appropriate window configuration change hooks, but didn't, because I'm
> lazy and my approach is fast enough for me.
> ;; Don't do this.
> (defun window-highlight--pre-redisplay (_window)
> (window-highlight--rescan-windows))
> (add-function :after pre-redisplay-function
> #'window-highlight--pre-redisplay))
> What I'd have wanted instead is something like this:
> (run-when-changed
> (list (selected-window) (selected-frame) (frame-focus-state))
> #'window-highlight--rescan-windows)
> Here, we'd run window-highlight--rescan-windows only when one of its
> dependent conditions (e.g. selected frame) changed. After any number of
> window and frame changes, we'd run window-highlight--rescan-windows
> *once*, immediately before its effects would become user-visible
> (e.g. just before redisplay, or after commands), and we wouldn't re-run
> it until one of its preconditions changed.
Can your proposal also handle whether user moves cursor?
Another reason why post-command-hook is used is mostly for run code
when user moves cursor position.
post-command-hook would run code even if user/cursor is idle and even
for every /(unrelated)/ function in background, which can lead to high
resource consumption.
I think having alternatives like this for specific commands (or actions)
could help reduce the use of post-command-hook.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 01:04:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 77224 <at> debbugs.gnu.org (full text, mbox):
On March 28, 2025 8:40:36 PM EDT, "Elijah Gabe Pérez" <eg642616 <at> gmail.com> wrote:
>Daniel Colascione <dancol <at> dancol.org> writes:
>
>> The feature I'm proposing is higher-level than that. For example, for
>> my personal use, I have something that sits in pre-redisplay-function
>> and scans all the windows for applying highlights based on current
>> buffer and window selection. I should have written this thing using the
>> appropriate window configuration change hooks, but didn't, because I'm
>> lazy and my approach is fast enough for me.
>
>> ;; Don't do this.
>
>> (defun window-highlight--pre-redisplay (_window)
>> (window-highlight--rescan-windows))
>
>> (add-function :after pre-redisplay-function
>> #'window-highlight--pre-redisplay))
>
>> What I'd have wanted instead is something like this:
>
>> (run-when-changed
>> (list (selected-window) (selected-frame) (frame-focus-state))
>> #'window-highlight--rescan-windows)
>
>> Here, we'd run window-highlight--rescan-windows only when one of its
>> dependent conditions (e.g. selected frame) changed. After any number of
>> window and frame changes, we'd run window-highlight--rescan-windows
>> *once*, immediately before its effects would become user-visible
>> (e.g. just before redisplay, or after commands), and we wouldn't re-run
>> it until one of its preconditions changed.
>
>Can your proposal also handle whether user moves cursor?
>
>Another reason why post-command-hook is used is mostly for run code
>when user moves cursor position.
I don't see why not? You could put (point) on your change list or something. I'm imagining that we just recognize forms in this list specially and add the appropriate low level hooks internally.
>post-command-hook would run code even if user/cursor is idle and even
>for every /(unrelated)/ function in background, which can lead to high
>resource consumption.
Yeah. Tragedy of the commons. Too many sheep grazing on the communal Emacs event loop.
>
>I think having alternatives like this for specific commands (or actions)
>could help reduce the use of post-command-hook.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 02:54:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி மார்ச் 28, 2025] Eli Zaretskii wrote:
> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data? Just yesterday someone
> complained on Reddit that Emacs is too slow, and I have no doubt that
> features that use post-command-hook are at least part of the reason if
> not _the_ reason.
CAVEAT: I am aware of the ill effects of having too many things in
post-command-hook and generally avoid it unless strictly necessary.
In the message-mode buffer I'm writing this from:
(t flyspell-post-command-hook)
In Org mode:
(prettify-symbols--post-command-hook t)
In f90-mode:
(jit-lock--antiblink-post-command eldoc-schedule-timer t)
In elisp-mode:
(jit-lock--antiblink-post-command eldoc-schedule-timer
reveal-post-command t)
Global value:
(transient--post-command-hook repeat-post-hook)
I have no idea why transient--post-command-hook is in there. I don't
use transient at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 07:04:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: eg642616 <at> gmail.com, 77224 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Fri, 28 Mar 2025 17:49:44 +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: Fri, 28 Mar 2025 16:40:29 +0100
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> My `post-command-hook' list looks like this:
> >>
> >> Buffer-local:
> >> (jit-lock--antiblink-post-command eldoc-schedule-timer
> >> corfu--auto-post-command jinx--reschedule
> >> whitespace-post-command-hook hl-line-highlight t)
> >
> > And in Org buffers?
>
> The first list was from the *scratch* buffer. This one is from an Org
> buffer:
>
> (eldoc-schedule-timer corfu--auto-post-command jinx--reschedule
> whitespace-post-command-hook hl-line-highlight t)
That's already problematic, IMO. And then some people might enable
flyspell-mode on top of all that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 07:53:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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: Fri, 28 Mar 2025 17:49:44 +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: Fri, 28 Mar 2025 16:40:29 +0100
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> My `post-command-hook' list looks like this:
>> >>
>> >> Buffer-local:
>> >> (jit-lock--antiblink-post-command eldoc-schedule-timer
>> >> corfu--auto-post-command jinx--reschedule
>> >> whitespace-post-command-hook hl-line-highlight t)
>> >
>> > And in Org buffers?
>>
>> The first list was from the *scratch* buffer. This one is from an Org
>> buffer:
>>
>> (eldoc-schedule-timer corfu--auto-post-command jinx--reschedule
>> whitespace-post-command-hook hl-line-highlight t)
>
> That's already problematic, IMO. And then some people might enable
> flyspell-mode on top of all that.
In my experience, there is no problem, neither in Org nor in Elisp
buffers. I wrote in my other mail:
>> I don't have any problems with these hooks, since they are either
>> cheap or only schedule some timers for more expensive operations. At
>> least I don't notice any sluggishness and the PCHs don't appear in
>> profiles.
Enabling Flyspell on top is not a realistic scenario since
`jinx--reschedule' comes from the Jinx spell checker, which is an
alternative to Flyspell. The spell checking takes place later when Emacs
is idle. The functions `jinx--reschedule', `eldoc-schedule-timer' and
`corfu--auto-post-command' only schedule timers.
The `hl-line-highlight' moves the line highlight overlay, such that it
moves immediately with the cursor and does not lag behind. This is a
similar scenario to changing the `cursor-type', where the cursor type
should immediately reflect the editing state. Yes, we will check the
cursor conditions too often, and often unnecessarily, but this does not
cause slowdown as long as the check is sufficiently fast in comparison
to the executed command.
The only seemingly problematic hook is `whitespace-post-command'. I
haven't checked it in detail. It looks complex but it mostly seems to
modify some overlays and trigger fontification. Potentially some of the
work there could be deferred.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 07:53:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 28 Mar 2025 21:03:10 -0400
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: Eli Zaretskii <eliz <at> gnu.org>, mail <at> daniel-mendler.de, juri <at> linkov.net,
> 77224 <at> debbugs.gnu.org
>
> >Can your proposal also handle whether user moves cursor?
> >
> >Another reason why post-command-hook is used is mostly for run code
> >when user moves cursor position.
>
> I don't see why not? You could put (point) on your change list or something. I'm imagining that we just recognize forms in this list specially and add the appropriate low level hooks internally.
>
> >post-command-hook would run code even if user/cursor is idle and even
> >for every /(unrelated)/ function in background, which can lead to high
> >resource consumption.
>
> Yeah. Tragedy of the commons. Too many sheep grazing on the communal Emacs event loop.
Yes, for this kind of feature to work in Emacs, there should be some
mechanism that would scan all the important changes (whose name is a
legion), and signal the relevant changes to potential clients. That
sounds like one giant end probably quite expensive post-command-hook,
doesn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 08:01:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77224 <at> debbugs.gnu.org,
> eg642616 <at> gmail.com, juri <at> linkov.net
> Date: Sat, 29 Mar 2025 08:23:13 +0530
>
> Global value:
>
> (transient--post-command-hook repeat-post-hook)
>
> I have no idea why transient--post-command-hook is in there. I don't
> use transient at all.
Maybe you used some feature that loads transient, like emoji-insert?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 08:18:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> 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.
> The only seemingly problematic hook is `whitespace-post-command'. I
> haven't checked it in detail. It looks complex but it mostly seems to
> modify some overlays and trigger fontification. Potentially some of the
> work there could be deferred.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 08:33:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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.
Some specialized code could handle this overlay such that it is treated
more efficiently together with the cursor itself. But in practice not
much would be won given that the `hl-line-overlay' has never caused
noticeable problems. Maybe it has for others and likely in files with
very long lines? For files with long lines I still use `so-long-mode'.
Daniel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 08:52:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> 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?
My point was and remains the same: adding more and more features to
post-command-hook is something to be avoided.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 09:19:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 77224 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 10:08:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 77224 <at> debbugs.gnu.org (full text, mbox):
On 29 March 2025 13:30:38 GMT+05:30, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77224 <at> debbugs.gnu.org,
>> eg642616 <at> gmail.com, juri <at> linkov.net
>> Date: Sat, 29 Mar 2025 08:23:13 +0530
>>
>> Global value:
>>
>> (transient--post-command-hook repeat-post-hook)
>>
>> I have no idea why transient--post-command-hook is in there. I don't
>> use transient at all.
>
>Maybe you used some feature that loads transient, like emoji-insert?
No, I never did. I essentially never use any transient based command since it is far too complex for my simpleminded brain.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 12:16:03 GMT)
Full text and
rfc822 format available.
Message #200 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 17:58:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data? Just yesterday someone
> complained on Reddit that Emacs is too slow, and I have no doubt that
> features that use post-command-hook are at least part of the reason if
> not _the_ reason.
this is what i have in every prog mode:
(eldoc-schedule-timer
treesit-fold-indicators--post-command
jit-lock--antiblink-post-command
fill-indicator--set-warning
indent-bars--highlight-current-depth
goggles--post-command
corfu--auto-post-command
yas--post-command-handler
whitespace-post-command-hook
t
eldoc-box--follow-cursor)
Most of these functions uses this hook for run code when cursor changes
position since there is not a hook for that (yet).
I think there should be a entry in etc/TODO for hooks when:
- buffer content changes
- cursor changes position
- undo (and redo) commands are used.
- rendering/displaying frame content (thus the code would not run for every function).
This would reduce post-command-hook usage and help Emacs ecosystem a lot.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 18:27:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>> I've updated the patch which should use the mode hook instead using
>> post-command-hook or idle timers (and allows (implicitly) to user use
>> post-command-hook (but that is user responsibility add it or not)).
>> Also this should refresh the cursor while switching windows.
>> However I've deleted the function/lambdas support as conditions because
>> i found it problematic.
>> I've test it only for overwrite-mode, I ask if anyone wants to give it a
>> try.
> Please note that this is insufficient for 'repeat-mode'.
> Currently it requires adding an advice to update the cursor
> on the repeat timer events:
> (add-function :after repeat-echo-function #'cursor-indicators--update-indications)
> since need to update the cursor when the timer is fired:
> (run-with-idle-timer timeout nil #'repeat-exit)
> (defun repeat-exit ()
> (setq repeat-in-progress nil)
> (funcall repeat-echo-function nil))
> This problem can be solved by adding a hook:
> (defun repeat-exit ()
> (setq repeat-in-progress nil)
> (funcall repeat-echo-function nil)
> (run-hooks 'repeat-exit-hook))
> Then 'cursor-indicators-mode' needs to add this hook:
> (define-minor-mode cursor-indicators-mode
> ...
> (add-hook 'repeat-exit-hook #'cursor-indicators--update-indications)
> Then maybe it's possible to add more hooks for other features as well.
> The drawback of this approach is that specific hooks make the cursor updating
> less reliable than with using post-command-hook.
Well, then I think the best solution for this would be to make this
package (cursor-indicators) part of the C code.
I'll see what I can do.
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sat, 29 Mar 2025 18:41:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77224 <at> debbugs.gnu.org, eliz <at> gnu.org, Daniel Colascione
> <dancol <at> dancol.org>, mail <at> daniel-mendler.de
> Date: Sat, 29 Mar 2025 12:26:40 -0600
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> I've updated the patch which should use the mode hook instead using
> post-command-hook or idle timers (and allows (implicitly) to user use
> post-command-hook (but that is user responsibility add it or not)).
>
> Also this should refresh the cursor while switching windows.
>
> However I've deleted the function/lambdas support as conditions because
> i found it problematic.
>
> I've test it only for overwrite-mode, I ask if anyone wants to give it a
> try.
>
> Please note that this is insufficient for 'repeat-mode'.
> Currently it requires adding an advice to update the cursor
> on the repeat timer events:
>
> (add-function :after repeat-echo-function #'cursor-indicators–update-indications)
>
> since need to update the cursor when the timer is fired:
>
> (run-with-idle-timer timeout nil #'repeat-exit)
> (defun repeat-exit ()
> (setq repeat-in-progress nil)
> (funcall repeat-echo-function nil))
>
> This problem can be solved by adding a hook:
>
> (defun repeat-exit ()
> (setq repeat-in-progress nil)
> (funcall repeat-echo-function nil)
> (run-hooks 'repeat-exit-hook))
>
> Then 'cursor-indicators-mode' needs to add this hook:
>
> (define-minor-mode cursor-indicators-mode
> …
> (add-hook 'repeat-exit-hook #'cursor-indicators–update-indications)
>
> Then maybe it's possible to add more hooks for other features as well.
>
> The drawback of this approach is that specific hooks make the cursor updating
> less reliable than with using post-command-hook.
>
> Well, then I think the best solution for this would be to make this
> package (cursor-indicators) part of the C code.
>
> I'll see what I can do.
Let's please discuss your ideas before you implement them, to make
sure you don't work on some ideas that we might object to.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sun, 30 Mar 2025 18:02:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 77224 <at> debbugs.gnu.org (full text, mbox):
>> Please note that this is insufficient for 'repeat-mode'.
>> Currently it requires adding an advice to update the cursor
>> on the repeat timer events:
>
> I solved this problem by wrapping the `repeat-echo-function' and `after-focus-change-function'.
>
> https://gist.github.com/jdtsmith/a169362879388bc1bdf2bbb977782d4f
Interesting to see that you switched from `post-command-hook'
to `repeat-echo-function' and `after-focus-change-function'.
So we could have an option that allows switching between 1) idle timers,
2) 'post-command-hook', 3) a list of more specific hooks.
In any case we still need to add such a condition:
(if (memq 'repeat-in-progress cursor-indicators-conditions)
(add-function :after repeat-echo-function #'cursor-indicators--update-indications)
(remove-function :after repeat-echo-function #'cursor-indicators--update-indications))
that have to be added only when the customized value contains 'repeat-in-progress'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Sun, 30 Mar 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> Please note that this is insufficient for 'repeat-mode'.
>>> Currently it requires adding an advice to update the cursor
>>> on the repeat timer events:
>>
>> I solved this problem by wrapping the `repeat-echo-function' and `after-focus-change-function'.
>>
>> https://gist.github.com/jdtsmith/a169362879388bc1bdf2bbb977782d4f
>
> Interesting to see that you switched from `post-command-hook'
> to `repeat-echo-function' and `after-focus-change-function'.
>
> So we could have an option that allows switching between 1) idle timers,
> 2) 'post-command-hook', 3) a list of more specific hooks.
>
> In any case we still need to add such a condition:
>
> (if (memq 'repeat-in-progress cursor-indicators-conditions)
> (add-function :after repeat-echo-function #'cursor-indicators--update-indications)
> (remove-function :after repeat-echo-function #'cursor-indicators--update-indications))
>
> that have to be added only when the customized value contains 'repeat-in-progress'.
This is exactly the sort of complexity that nobody but those on this
thread will care about and that we need to abstract behind some
stupid-easy DWIM interface.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 31 Mar 2025 23:42:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Let's please discuss your ideas before you implement them, to make
> sure you don't work on some ideas that we might object to.
Sure.
The code needs to run each time the cursor moves, (is there
a function/code that do this?) and each time user changes window
(because cursor color is not buffer-local).
I think that using variable watchers would be better and keep
this defcustom (it will only use variables):
#+begin_example
(defcustom cursor-indicators
'((overwrite-mode . "red")
(buffer-read-only "green" hollow)
(current-input-method . "blue"))
[...]
#+end_example
[Message part 2 (text/html, inline)]
[Message part 3 (text/plain, inline)]
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Tue, 01 Apr 2025 11:44:03 GMT)
Full text and
rfc822 format available.
Message #221 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77224 <at> debbugs.gnu.org, dancol <at> dancol.org, mail <at> daniel-mendler.de,
> juri <at> linkov.net
> Date: Mon, 31 Mar 2025 17:41:15 -0600
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Let's please discuss your ideas before you implement them, to make
> sure you don't work on some ideas that we might object to.
>
> Sure.
>
> The code needs to run each time the cursor moves, (is there
> a function/code that do this?) and each time user changes window
> (because cursor color is not buffer-local).
I understand the general idea, but did you have more detailed ideas
for how to implement that?
And I'm not sure I understand why cursor movement needs this to run,
since the cursor appearance doesn't depend on its position, it depends
on state of overwrite-mode, buffer-read-only, and other similar state
variables, which don't change with buffer or cursor position. So what
am I missing?
> I think that using variable watchers would be better and keep
> this defcustom (it will only use variables):
>
>
> (defcustom cursor-indicators
> '((overwrite-mode . "red")
> (buffer-read-only "green" hollow)
> (current-input-method . "blue"))
> [...]
If each state has a variable you can watch, then yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Thu, 03 Apr 2025 23:09:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 77224 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: 77224 <at> debbugs.gnu.org, dancol <at> dancol.org, mail <at> daniel-mendler.de,
>> juri <at> linkov.net
>> Date: Mon, 31 Mar 2025 17:41:15 -0600
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> Let's please discuss your ideas before you implement them, to make
>> sure you don't work on some ideas that we might object to.
>>
>> Sure.
>>
>> The code needs to run each time the cursor moves, (is there
>> a function/code that do this?) and each time user changes window
>> (because cursor color is not buffer-local).
>
> I understand the general idea, but did you have more detailed ideas
> for how to implement that?
Maybe in a kind of loop?
I'm still thinking.
Another idea is to make the cursor color buffer local.
> And I'm not sure I understand why cursor movement needs this to run,
> since the cursor appearance doesn't depend on its position, it depends
> on state of overwrite-mode, buffer-read-only, and other similar state
> variables, which don't change with buffer or cursor position. So what
> am I missing?
Because I had planned to implement this part of the TODO for this
package (since I think it fits for this):
(L848) ** Optionally make the cursor a little thinner at EOL and EOB
Honestly, I'm getting a little tired, so I'm going to put this on pause
until I come up with an idea or someone wants to work on it.
--
- E.G via GNU Emacs and Org.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 04 Apr 2025 06:18:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> Because I had planned to implement this part of the TODO for this
> package (since I think it fits for this):
>
> (L848) ** Optionally make the cursor a little thinner at EOL and EOB
With your initial implementation it's easy to customize it to just
(setopt cursor-indicators-conditions
'((eolp . bar)))
(Note that you even don't need 'eobp'
since it's always covered by 'eolp'.)
So why not go with your initial implementation that works great.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 04 Apr 2025 10:50:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77224 <at> debbugs.gnu.org, juri <at> linkov.net, dancol <at> dancol.org,
> mail <at> daniel-mendler.de
> Date: Thu, 03 Apr 2025 17:08:41 -0600
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> The code needs to run each time the cursor moves, (is there
> >> a function/code that do this?) and each time user changes window
> >> (because cursor color is not buffer-local).
> >
> > I understand the general idea, but did you have more detailed ideas
> > for how to implement that?
>
> Maybe in a kind of loop?
> I'm still thinking.
The place where Emacs sets the cursor is well-defined, but calling
display-related functions from there could be tricky, because we are
in the middle of redisplay at that point.
I would first suggest to try using window-scroll-functions for this
purpose, maybe they are all you need.
> > And I'm not sure I understand why cursor movement needs this to run,
> > since the cursor appearance doesn't depend on its position, it depends
> > on state of overwrite-mode, buffer-read-only, and other similar state
> > variables, which don't change with buffer or cursor position. So what
> > am I missing?
>
> Because I had planned to implement this part of the TODO for this
> package (since I think it fits for this):
>
> (L848) ** Optionally make the cursor a little thinner at EOL and EOB
That could be a separate feature, implemented differently.
> Honestly, I'm getting a little tired, so I'm going to put this on pause
> until I come up with an idea or someone wants to work on it.
Understood. Apologies if I added to your tiredness.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Fri, 11 Apr 2025 16:29:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 77224 <at> debbugs.gnu.org (full text, mbox):
>> (L848) ** Optionally make the cursor a little thinner at EOL and EOB
>
> With your initial implementation it's easy to customize it to just
>
> (setopt cursor-indicators-conditions
> '((eolp . bar)))
Shouldn't 'cursor-indicators' use 'pre-redisplay-functions'
like 'cursor-face-highlight-mode' does?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 14 Apr 2025 04:36:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 77224 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Elijah Gabe Pérez writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >> Cc: 77224 <at> debbugs.gnu.org, dancol <at> dancol.org, mail <at> daniel-mendler.de,
> >> juri <at> linkov.net
> >> Date: Mon, 31 Mar 2025 17:41:15 -0600
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> Let's please discuss your ideas before you implement them, to make
> >> sure you don't work on some ideas that we might object to.
> >>
> >> Sure.
> >>
> >> The code needs to run each time the cursor moves, (is there
> >> a function/code that do this?) and each time user changes window
> >> (because cursor color is not buffer-local).
> >
> > I understand the general idea, but did you have more detailed ideas
> > for how to implement that?
>
> Maybe in a kind of loop?
> I'm still thinking.
>
> Another idea is to make the cursor color buffer local.
I got an idea, what about add an advice-add to setq as a kind of variable
watcher? setq is the standard for changing the value to a variable, and
compared to post-command-hook, it wouldn't run on every function calls, ofc
the advice will be removed after disabling the minor mode.
Maybe it sounds hacky and could already been talked about in this thread
that I've missed, but there are built-in packages in emacs that use
advice-add.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77224; Package
emacs.
(Mon, 14 Apr 2025 05:16:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 77224 <at> debbugs.gnu.org (full text, mbox):
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Sun, 13 Apr 2025 22:34:47 -0600
> Cc: 77224 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>,
> Daniel Colascione <dancol <at> dancol.org>, Daniel Mendler <mail <at> daniel-mendler.de>
>
> >> The code needs to run each time the cursor moves, (is there
> >> a function/code that do this?) and each time user changes window
> >> (because cursor color is not buffer-local).
> >
> > I understand the general idea, but did you have more detailed ideas
> > for how to implement that?
>
> Maybe in a kind of loop?
> I'm still thinking.
>
> Another idea is to make the cursor color buffer local.
>
> I got an idea, what about add an advice-add to setq as a kind of variable watcher? setq is the standard for
> changing the value to a variable, and compared to post-command-hook, it wouldn't run on every function
> calls, ofc the advice will be removed after disabling the minor mode.
>
> Maybe it sounds hacky and could already been talked about in this thread that I've missed, but there are
> built-in packages in emacs that use advice-add.
If that's what you want, why not use a variable watcher directly? We
do that in some cases already, see the end of frame.el.
This bug report was last modified 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.