bug#28864: 25.3.50; next-error-no-select does select

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/25/17 1:23 AM, Dmitry Gutov wrote:
> On 10/24/17 11:22 PM, Juri Linkov wrote:
> 
>> So do you propose to prefer buffer-local next-error-last-buffer
>> instead of window-local next-error-last-buffer?
> 
> Maybe something like this:
> 
> - Make next-error-last-buffer always buffer-local.
> 
> - Create the "current next-error source buffer" variable (which we'll 
> need anyway), and whenever we need to look up or set 
> next-error-last-buffer, read it or set it in that buffer.

Sorry, this is nonsense, since next-error-last-buffer contains the 
reference to the "current next-error source buffer" anyway.

Let me amend it.

I propose to use next-error-last-buffer's global value, and avoid 
changing it too easily. Mostly at the user's request (via a special 
command), or when the last next-error-last-buffer has run out of errors, 
and the current buffer has some (this will require some discussion, 
though; maybe add a user prompt?).

>> This can cause
>> problems only when the same buffer can be visited from separate
>> next-error navigations, e.g. from two different *grep* buffers,
>> next-error from such buffer will use only the latest navigation
>> that visited this buffer (until it switched manually to another
>> navigation by a new command) Is this situation frequent enough?

Is there a reason you thought of buffer-local next-error-last-buffer values?

The "current error" is not stored in this variable. Instead, it's 
"saved" in the value of point in the corresponding error-capable buffer.