emacs-devel
[Top][All Lists]
Advanced

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

Re: Select completions from the minibuffer


From: Eli Zaretskii
Subject: Re: Select completions from the minibuffer
Date: Fri, 18 Mar 2022 13:33:20 +0200

> Date: Fri, 18 Mar 2022 12:16:08 +0100
> From: Ergus <spacibba@aol.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org, juri@linkov.net
> 
> When moving point redisplay--pre-redisplay-functions is called BUT
> receives nil in the list of windows to update, so it goes in the first
> part of the if and runs the hooks for the selected-window
> only.

And this is incorrect, i.e. the actual window to be redisplayed is NOT
the selected window?

> (actually this code looks like a workaround for that situation)
> 
> (if (null windows)
>          (with-current-buffer (window-buffer (selected-window))
>            (run-hook-with-args 'pre-redisplay-functions (selected-window)))
>        (dolist (win (if (listp windows) windows (window-list-1 nil nil t)))
>          (with-current-buffer (window-buffer win)
>            (run-hook-with-args 'pre-redisplay-functions win))))

Why is it a workaround?  The doc string of pre-redisplay-function says
that if the argument is nil, it stands for the selected-window.

> In Juri's code it is moving the point in completions while in the
> minibuffer so *Completions* never becomes the active window and it is
> never passed to redisplay--pre-redisplay-functions.

I'd appreciate a test case for this, preferably independent of the
completion framework, so that I could look at what happens there.  It
sounds like you are saying that a window gets redrawn by the display
engine (because its point moved), but pre-redisplay-functions aren't
called for that window, which would be a bug, I think.



reply via email to

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