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

[Dmitry Gutov]

On 10/23/17 11:12 PM, Juri Linkov wrote:

> It's a step backward: it removes the ability to run several next-error
> navigations simultaneously.  Currently it's possible to visit e.g.
> compilation results in one frame, and e.g. grep hits in another frame
> at the same time without affecting one another.

Why removes? Each buffer should keep its "current error" state, and 
you'd switch between the navigations by switching to the 
errors-containing buffer (and calling some additional command), probably.

> Undoubtedly, relying
> on the frame confines or on the buffer visibility is far from ideal.

I'm not married to buffer visibility, just figured it would be the 
easiest to implement. And also, for the user to conceptualize.

If you implement switching between navigations even when all 
error-containing buffers are still buried, more power to you.

> One solution that I proposed was to associate a window containing
> a navigated buffer with its next-error capable buffer, so that
> next-error issued in the same window will continue visiting other matches
> from the same next-error buffer (regardless whether it's hidden or not).

It's *a* solution, for sure. But there is little about a window that 
indicates that an error-containing buffer is tied to it somehow, if it's 
not displayed in it.

Implicit state is not so great as a UI.

> This assumes there will be a command to disassociate a window
> from its next-error buffer, and switch to another next-error buffer.
>
> Do you have a better idea?

Like I said: just adding a command that makes the current buffer the 
next-error buffer. The user will have to switch to it, that may be an 
extra step, but they'd have to specify the target buffer anyway, so 
switching shouldn't make a lot of difference, keystroke-wise.