bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#59918: 29.0.60; query-replace in the minibuffer lazy-highlights orig


From: Augusto Stoffel
Subject: bug#59918: 29.0.60; query-replace in the minibuffer lazy-highlights original buffer
Date: Mon, 12 Dec 2022 20:05:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

On Mon, 12 Dec 2022 at 20:07, Eli Zaretskii wrote:

>> Cc: 59918@debbugs.gnu.org
>> From: Juri Linkov <juri@linkov.net>
>> Date: Mon, 12 Dec 2022 19:43:25 +0200
>> 
>> >> 1. (setq enable-recursive-minibuffers t)
>> >> 1. M-! is C-a
>> >> 2. M-% is
>> >>
>> >> Matches are lazy-highlighted in the original buffer,
>> >> but the replacement is going to be used to replace
>> >> matches in the minibuffer.
>> >
>> > I guess this happens because minibuffer-selected-window returns the
>> > original buffer.  I think this patch does the trick?
>> 
>> We need to wait until Eli decides whether to install this
>> to emacs-29 or master.
>
> I admit that I don't understand the patch.  minibuffer-selected-window
> returns a window, not a buffer, and it returns the window that you
> didn't want, AFAIU.

The check in the patch is whether the buffer of the
minibuffer-selected-window is the current buffer.  It's meant to fail
when you are about to start a recursive minibuffer.

> Or maybe I don't understand the root cause -- could one of you please
> elaborate on what happens and why this is the right patch?

The original code assumed that when you are about to activate a
minibuffer, the current buffer will become the (window-buffer
(minibuffer-selected-window)).  This is not true if you are entering a
recursive minibuffer, hence the check.

It may or may not be the best patch, but I would say it's the safe one
if were to fix this in Emacs 29.  I would also say the issue rare and
basically cosmetic.

> Also, was this code introduced in Emacs 28/29 or earlier?

New in Emacs 29.





reply via email to

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