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

[Trevor Spiteri]

>> The next-error-select-buffer documentation states that “the selected
>> buffer becomes the source of locations for the subsequent invocation of
>> ‘next-error’ or ‘previous-error’.” However, it is not the case for the
>> following:
>>
>> 1. Go in a fresh next-error capable buffer (not *grep*).
>> 2. Grep for something.
>> 3. M-x next-error-select-buffer *grep*
>> 4. M-x next-error
>>
>> The buffer of 1 (not *grep*) is the source of locations instead of
>> the expected *grep*.
>>
>> This is because although next-error-select-buffer sets the variable
>> next-error-last-buffer, it is not used in this case: When next-error
>> calls next-error-find-buffer, next-error-buffer has no buffer-local
>> value yet, so condition 2. in next-error-find-buffer (that
>> next-error-buffer has no buffer-local value and the current buffer is a
>> next-error capable buffer) is true, and the function never even checks
>> next-error-last-buffer.
> Thanks for the report.  Do you think the problem is in implementation,
> or only in documentation?  IOW, do you think its behavior is correct,
> but the documentation should be fixed to describe more clearly what
> next-error was intended to do in this situation?

I think the error is in the implementation. In fact I added a later
comment to the bug report.


> And I just realized, this is also a regression from Emacs 26 if step 3
> is skipped, as step 2 itself also sets next-error-last-buffer .

As a use case, let's say I'm in a buffer that has next-error
capabilities because of say flycheck, and I grep or compile; I want to
start going through the new errors immediately. That is why
compilation-start finishes  with (setq next-error-last-buffer outbuf)
and that's how Emacs 26 works (without step 3 as
next-error-select-buffer is new). In Emacs 27 not only does that break,
but even using the new function has no effect.