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

[Dmitry Gutov <dgutov@yandex.ru>]

On 11/3/17 12:00 AM, Juri Linkov wrote:

>> I'm not sure either can be congruent to all next-error-function
>> applications. Some next-error source buffers contain their own errors (so
>> buffer-local is natural), and others point to errors in other buffers
>> (supposing they can learn to open those in the same window, window-local
>> might be fitting). But both kinds are there, and all users deal with both.
> 
> They can learn to open those in the same window by the patch below.

If 'next-error', from any source, opens its target in the same window, 
does that make window-local storage essentially the same as frame-local 
in practice?

>>> 3. frame-local - old implicit default now separated into its own function
>>
>> That doesn't sound like a sufficient description: the old default also
>> includes visibility-based logic. So it's not just one value per frame.
> 
> Do you think we should use the real frame-parameter?

I almost never use more than one frame, so I wouldn't know. But if you 
use a frame-parameter only, won't that break backward compatibility?

>> is the new next-error-find-buffer stuff necessary to
>> fix the current bug? Or is suppressing the change to next-error-last-buffer
>> during next-error-function calls enough for that?
> 
> The key point is (setq next-error-last-buffer) after
> (funcall next-error-function), not before.

Thanks. So maybe we can split your patch into two parts: one that fixes 
the complaint in just this bug report, and the rest that aims to improve 
the general behavior.

We could push the first one right away, and continue discussing the 
second one. I'd like to see some new voices too, not just us two.

>> Why not use "current" here as well? After all, we pass 0 to
>> next-error-function here.
> 
> OK, here is the next patch:

Thanks.