Re: next-error use cases

[Stephen Leake]

Juri Linkov <address@hidden> writes:

>>> 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.
>
> I don't understand what do you mean by indication?  Is it a visual
> indication somewhere?  I grepped for 'compilation-last-buffer', but in
> compile.el 'compilation-last-buffer' is an alias for 'next-error-last-buffer',
> and grep.el contains commented out definition whose purpose I don't
> know:

Use xref: in *scratch*, type compilation-last-buffer, hit M-. (bound to
xref-find-definitions).

That takes you to the definition in compile.el, which is a defalias for
next-error-last-buffer. Invoke M-. on that, it takes to you simple.el:

(defvar next-error-last-buffer nil
  "The most recent `next-error' buffer.
A buffer becomes most recent when its compilation, grep, or
similar mode is started, or when it is used with \\[next-error]
or \\[compile-goto-error].")

>> 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.
>
> But how can you reset it when the location list is in the same buffer
> like in case of flyspell where locations of misspelled words are
> in the same buffer where next-error navigates, or flymake where
> locations of errors/warnings are in the same buffer?

Position point on an error message, hit enter.

-- 
-- Stephe