bug#32607: 27.0.50; pop-to-buffer in next-error-no-select

[Juri Linkov <juri@linkov.net>]

>> The special case is in next-error-no-select.  Its purpose is to display
>> the next-error buffer (the buffer with the location of the next-error),
>> not to display next-error-last-buffer (the buffer with the list of errors)
>> because next-error-last-buffer is already displayed.  The user runs
>> next-error-no-select from the selected window that already displays
>> next-error-last-buffer, there is no need to try and display the same
>> buffer again.  This behavior is not even documented.  So pop-to-buffer
>> is useless here.  But I suspect that maybe it was added for some use cases
>> to ensure that next-error-last-buffer is displayed.  So at least
>> we need to make it harmless.  But currently it makes harm with the
>> reported configuration.  I provided a patch to fix next-error-no-select
>> to not fail with the legitimate user configuration.
>
> I suppose the idea is to implicitly emphasize the "-no-select" postfix
> by showing 'next-error-buffer' somewhere and simultaneously selecting
> a window showing 'next-error-last-buffer'.  That's a rather unpleasant
> hack, your analysis is correct and 'display-buffer-overriding-action'
> is a valid remedy here (it's at least as good as
>
>   (unless (get-buffer-window next-error-last-buffer)
>     (pop-to-buffer next-error-last-buffer))
>
> IMHO) so install it.

Sorry that I failed to explain this earlier, but it just occurred to me
that the purpose of pop-to-buffer in next-error-no-select is to switch
the selected window to next-error-last-buffer from the buffer's window
with next-error.  Because when I tried your code it failed by leaving
point in wrong window: after this command point should be back in the
next-error-last-buffer window, but without calling pop-to-buffer
it remains in the window with the next-error buffer.  The solution
with using display-buffer-overriding-action correctly puts point back
to select next-error-last-buffer window.