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

[martin rudalics]

>>  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