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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>        (save-selected-window
>>>          (let ((next-error-highlight next-error-highlight-no-select)
>>>                (display-buffer-overriding-action
>>>                 '(nil (inhibit-same-window . t))))
>>>            (next-error n)))
>>
>> This is much simpler.  Actually, this is what I wanted to propose as
>> a solution to Martin in one of previous messages, but I mistakenly wrote
>> save-window-excursion whereas I actually intended save-selected-window.
>
> I still do not understand whether we are sure that at the time the
> code above gets called 'next-error-last-buffer' is really shown in the
> selected window.

Indeed, I don't see any obvious indication that this is the case.
I suspect it's *usually* the case because next-error-no-select is only
bound to keys in "error buffers", but if you

    M-x next-error-no-select

from a C file, I suspect that the buffer shown in the selected-window at
the beginning of the command won't be equal to the next-error-last-buffer.

I'm not sure what would be considered the *right* behavior in that case:
should the selected-window at the end display the same buffer as at the
beginning, or should it show the buffer that contains the error
(e.g. *grep* or *compilation*)?

My own take on it is that it's perfectly OK to have the final
selected-window show the buffer in which the command was typed (rather
than the *grep*/*compilation* buffer).


        Stefan