Re: next-error-last-buffer

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 25 May 2004, juri@jurta.org wrote:

> Richard Stallman <rms@gnu.org> writes:
>> This fix has a drawback; it will make that buffer permanently
>> incapable of being used as a series of references to places.
>>
>> I think we should look for a way to disable this temporarily instead.
>> However, I am not sure how that would work--what would be the
>> condition on which to reenable this buffer's value of
>> next-error-function?
> 
> If there is a real need to enable next-error-function in the existing
> buffer visited by next-error (i.e. if it's not too rare case when the
> user needs to kill a buffer and create a new, that may be inconvenient
> if performed too often), then next-error-function could be enabled again
> by setting it to the initial value by typing C-m or one of other error
> visiting keys available in the next-error capable buffer.  When these
> keys are bound to one of the following functions, each function could
> set the initial value of next-error-function every time it called
> in the next-error capable buffer:
> 
> compile-goto-error
> diff-goto-source
> occur-mode-goto-occurrence

I think your proposal forces the user to do something unexpected in
the flow of their work.  It's not a terrible solution, if it's the
only one we have, but I would prefer to do it in a different way:

Maybe if there's more than one next-error capable buffers that are
linked together (e.g. occur on a diff) then C-u next-error should
advance through the "underlying" next-error buffer (the diff) while
next-error should advance through the "overlay" next-error buffer
(the occur).  If the user does a grep on an occur on a diff, for
instance, then C-u C-u next-error advances through the diff, C-u
next-error advances through the occur, and next-error advances
through the grep.

Does this approach seem useful?

Ted