GNU bug report logs - #47894
28.0.50; isearch does not work if enable-recursive-minibuffers is on and some input method is set.

Previous Next

Packages: emacs, gnus;

Reported by: max.brieiev <at> gmail.com

Date: Mon, 19 Apr 2021 16:08:01 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Gregory Heytings <gregory <at> heytings.org>, Juri Linkov <juri <at> linkov.net>
Cc: max.brieiev <at> gmail.com, 47894 <at> debbugs.gnu.org
Subject: bug#47894: 28.0.50; isearch does not work if enable-recursive-minibuffers is on and some input method is set.
Date: Wed, 21 Apr 2021 09:03:27 +0200
>>  It failed to work when buffer is auto selected via
>>  `display-buffer-alist’.  When the point moves to the *Occur* buffer,
>>  typing “n”, “p” still sends “n”, “p” to isearch.
>>
>>  (defun display-buffer-select (buffer alist)
>>    (let ((window (display-buffer-below-selected buffer alist)))
>>      (when (window-live-p window)
>>        (select-window window))))
>>
>>  (setq display-buffer-alist '(("\\*Occur\\*" (display-buffer-select))))
>>
>> Maybe this could be handled as well?
>>
>
> And this one is strange, too, for two reasons:
>
> - display-buffer-select is not a documented action, and does not even appear in the sources (even Google does not find it!), yet it works;

I don't understand you here.  It is defined above as a function based on
`display-buffer-below-selected' with the additional twist that it tries
to select the window chosen.  Which is arguably not the task of a
display buffer action function - `pop-to-buffer' should be used for that
purpose.

> - After this action, point has moved, but (current-buffer) does not return the buffer where point is; (window-buffer (selected-window)) does.  It seems to me that at the top-level these two should always be equal; apparently they are not.

They need not be equal - only command_loop_1 ascertains that once here

      /* Make sure the current window's buffer is selected.  */
      set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents));

but `display-buffer' can be called anywhere.  The major point is that,
due to the fact that `display-buffer' may pop up a new frame and the WM
will usually focus that frame, an application can _never_ be sure which
window will get selected and which buffer will be current after calling
`display-buffer' finished.

martin





This bug report was last modified 4 years and 35 days ago.

Previous Next


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