bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented

[Trevor Spiteri]

>> I think this would work for next-error-select-buffer. Then to fix the
>> other issue about new compilations, compilation-start can be modified to
>> use next-error-select-buffer. That way the change in compilation-start
>> is morally unambiguous :)
> I'm not sure if this is morally right, because users might want to
> continue to navigate an old next-error buffer, even after creating
> a new next-error buffer.
>
> OTOH, by using next-error-select-buffer they explicitly say that
> they want to switch to the new navigation.  Do you think it's right
> to implicitly assume the user's intention?
>
> We should base the decision not on precedence set by older versions,
> but on expectations of most users.
>
>> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
>> index 455f181f50..41e77007c6 100644
>> --- a/lisp/progmodes/compile.el
>> +++ b/lisp/progmodes/compile.el
>> @@ -1910,7 +1910,7 @@ compilation-start
>>      (goto-char (point-max))))
>>  
>>      ;; Make it so the next C-x ` will use this buffer.
>> -    (setq next-error-last-buffer outbuf)))
>> +    (next-error-select-buffer outbuf)))
>>  
>>  (defun compilation-set-window-height (window)
>>    "Set the height of WINDOW according to `compilation-window-height'."
> There are more places that set next-error-last-buffer: vc-git-grep, occur-1,
> xref.el...
>
> But I'm still not sure if this is a preferable behavior for most users.
> Maybe this needs a user option?

I thought that the change was unintentional. If it's intentional that's
another thing. If no one else complains then maybe most users prefer the
new behavior. I've already added advice to compilation-start so it's not
hard for me that I prefer the old behavior.