Re: next-error use cases

[Stephen Leake]

Juri Linkov <address@hidden> writes:

>>> > > Define some kind of priority between them?
>>> > I really doubt we can define priorities such that the user will always
>>> > want to see the errors of some "kind" before the others.
>>>
>>> Then maybe this problem has no workable solution at all, and we
>>> shouldn't try running all those features from the same command.
>>
>> We could try, but in cases of doubt, ask the user what "next-error"
>> function he wants to use (and provide some command for actively
>> switching between them).  For example, after calling "next-error" in
>> some dubious case, the user could be offered a list of functions to
>> choose between:
>>
>> - next Compile error from *compile*<dir>
>> - next Occur result from *scratch*
>> - next Grep result from *grep*<dir2>
>> ...
>
> Answering this after every next-error command would be too tedious for users,
> and it's not clear how to reduce the frequency of such questions, i.e.
> how to detect only dubious cases.
>
>> There could also be other interfaces to pick a next-error function (a
>> menu, or something like M-x list-buffers).
>
> Recently we created such command with the name ‘next-error-select-buffer’.
> Still too inconvenient for users to run this command explicitly.
> We need next-error to be more DWIM.

That's what 'compilation-last-buffer' is for; it indicates the buffer
containing the location list that is current.

As long as the user has a convenient way to set that, there's no
problem. In all my current use cases, it is first set by the command
that generated the location list. I can reset it by navigating to a
buffer, and using <return> to goto a location; after that, 'next-error'
continues using that list.

-- 
-- Stephe