Re: next-error-last-buffer

[Juri Linkov]

Ted Zlatanov <address@hidden> writes:
> Let me make sure I understand the problem and solution.
>
> When next-error is called in buffer X, it may pop the user into
> buffer Y.  We want to unset next-error-function in Y, so that
> next-error does not act in Y from that point on.

Correct.

> Couldn't this be achieved by making the next-error-last-buffer check
> in next-error-find-buffer precede the current-buffer check?

This change will solve the problem.

> We need to define a function next-error-follow-this-buffer that would
> set next-error-last-buffer to (current-buffer).  That way, users can
> force the behavior that now is the default, that next-error should act
> on (current-buffer) first and foremost.  I would bind
> next-error-follow-this-buffer to C-x ~ (which on US keyboards is
> Shift-` so remembering it is not too bad).

There is no need for an additional function and keybinding.  The action
you proposed (i.e. setting next-error-last-buffer to (current-buffer))
could be performed in location-visiting functions usually bound to C-m
and C-c C-c.

But there is even simpler solution for the user to select a buffer
for the next C-x `.

Taking into account the recent addition of a rule in
`next-error-find-buffer' which returns a buffer which is displayed
only in one window with a next-error capable buffer on the selected
frame, the user can simply remove the unwanted window with a
next-error capable buffer (e.g. *grep* buffer in the aforementioned
test case) from the selected frame and C-x ` will use the buffer from
the remaining window (e.g. a patch file) even if it is not the same as
next-error-last-buffer.

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.
...

-- 
Juri Linkov
http://www.jurta.org/emacs/