Re: next-error use cases

[Stephen Leake]

Juri Linkov <address@hidden> writes:

>>>> 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.
>>
>> The error message is usually visible only in the minibuffer, and only when
>> point is over the error.
>
> If it's impossible to reset it by hitting enter, then I think we have
> only these remaining options:
>
> 1. If next-error can't work without the requirement to have a list of
> Flyspell mistakes or Flycheck/Flymake errors/warnings printed in a separate
> buffer (like "*Occur*"), then such buffer can be possibly implemented
> as a hidden buffer with a leading space in its name like for example
> " *Flycheck locations*".  ‘next-error-select-buffer’ still should
> propose it as a candidate for selection.

That can work, as long as the buffer is truly hidden. The leading space
disables font-lock, so errors don't look like errors. And the leading
space may have other surprising consequences.

> 2. Flycheck provides its own keybinding ‘C-c ! n’ for ‘flycheck-next-error’
> that can be used to reset the navigation.  There are also analogous functions
> ‘flymake-goto-next-error’ and ‘flyspell-goto-next-error’.

It is not "goto-next-error" that should set the list, but rather
"goto-error-at-point". That's what "enter" does in a compilation-mode buffer.

"goto-next-error" can be invoked from some far away place, but must
refer to the current error list.

-- 
-- Stephe