Re: next-error-last-buffer

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 30 May 2004, rms@gnu.org wrote:

    >> So the only change needed is to modify the rule order like you proposed,
>     > which could look as below:
>     > 
>     > 1. If one window on the selected frame displays such buffer, return it.
>     > 2. If next-error-last-buffer is set to a live buffer, use that.
>     > 3. If the current buffer is a next-error capable buffer, return it.
>     > ...
> 
> That might solve the problem, but what you have written is very
> different:

[...]

> This change has the unpleasant side effect of eliminating any
> convenient way to control which buffer you want to take errors from.
> next-error-last-buffer takes precedence over everything else,
> so there is no way to deliberately override it.

Sorry.  Consider the attached patch, which does the right thing (the
first 3 rules you quoted from Juri's e-mail are implemented).

Overriding the selection of the next-error buffer is easily done with
C-x 1 or C-x 0 as appropriate, to make the one buffer of interest the
only buffer displayed.

> Using the current buffer is wrong only in one special case: where that
> buffer was found as the source locus for an error.  In all other
> cases, it is right to use the current buffer rather than
> next-error-last-buffer.

Yes, but "source locus for an error" is not easy to track - I pointed
out that it's conceivable that a user might do grep on occur on
compile; there's a lot of marginal cases that I'm not sure we have to
anticipate.  I think a simple algorithm, as stated above, is the
right way to approach the problem right now - and if not, we can
certainly change the algorithm as needed.

Ted