Re: next-error use cases

[Dmitry Gutov <dgutov@yandex.ru>]

On 24.05.2020 04:41, Clément Pit-Claudel wrote:
> On 23/05/2020 21.36, Dmitry Gutov wrote:
> 
>> For error navigation, it /could/ be a better idea, but IMHO it's like we'd be giving up and creating a parallel set of variables and commands for "local" errors. And necessitate a "muscle memory" context switch when one goes from "local" errors to "global" or back. One set of bindings would also have to be more awkward than the other.
> 
> Good points all around, and I don't have much more to contribute :)

Perhaps you have thoughts on which particular usage pattern is more 
prevalent?

I should add that we're currently defaulting to approach #1. Even if 
Flymake doesn't have bindings by default, we will add some, and they'll 
mirror Flycheck's ones by default.

As a result, we'll already have two parallel sets of bindings for 
"local" and other errors: next/previous-error and 
flymake-next/previous-error.

So the question is, is there a reasonable scheme to use 
next-error/previous-error for Flymake's errors without severe 
side-effects, or we should stay with the current situation.

Whereby I'll bind M-n and M-p to Flymake's commands locally and leave 
next-error/previous-error on M-g M-n/p.

>> There's also another wrinkle: I think there was a proposed feature for Flycheck to list errors for multiple files (or the whole project) together? 'next-error' could be handy for jumping between those too.
> We do this currently already, and the idea is that all external errors are converted into local errors on line 1.
> In the error list they appear with a file name and a line number in that file, so if you were to cycle errors relative to that list you would visit files one by one, and if you were to visit errors relative to the buffer you'd go through all local errors then jump to another file with errors, if any.

In that case, maybe one could say that Flycheck errors are not always 
"local" either?