Subject: Re: bug#47894: 28.0.50; isearch does not work if enable-recursive-minibuffers is on and some input method is set.

From: martin rudalics <[email-masked]>
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