Re: next-error use cases

[Dmitry Gutov <dgutov@yandex.ru>]

On 23.05.2020 05:26, Clément Pit-Claudel wrote:

>> Oh, its beginning was only a tiny bit earlier:
>>
>> https://lists.gnu.org/archive/html/emacs-devel/2018-04/msg00207.html
> 
> Thanks a lot.  I think I understand the issue better.
> 
> Hopefully the following isn't too silly.  Right now we use C-x ` for two fairly different purposes:
> 
> 1. We have a list of locations (typically lines and columns), and we want jump from one to the next, opening files and buffers as needed (that's the grep, occur, and compilation-mode cases).
> 2. We have a buffer with interesting locations, and we want to cycle through them (that's the flyspell, flymake, flycheck cases).
> 
> This sounds quite similar to what happens with the global and the local mark rings, actually.  To cycle through marks in the current buffer you use C-u C-SPC; to cycle through global marks you use C-x C-SPC.  So I wonder if it would make sense to have C-x ` cycle through locations that come from "location lists" (grep) and having, say, C-c ` cycle through locations that come from the current buffer (flyspell).
> 
> That doesn't fully solve the problem of picking which location list to cycle through, but it eliminates the confusion between local and global locations (as a logical consequence, I imagine C-c ` in a location list would most of the time just move to the next line, though in an occur or grep buffer with multiple lines of context it would jump to the next match)
> 
> Does this make sense?

I'm not a big fan of mark rings, personally. Never use them, and if they 
were good enough, would we still have the xref marker ring? Formerly 
known as find-tag marker ring.

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.

How to evaluate this option objectively, though? Maybe we should ask 
what kind of user behavior we expect most of the time.

If, when working with local errors, we expect the user to go between 
them, then use the "global" navigation commands to jump between 
locations from e.g. Compilation, then back to "local" errors, in a short 
period of time, then having two sets of commands might be optimal.

If, on the other hand, we rather expect the user not to interleave the 
uses of "local" and "global" location lists as often, that the switches 
between sources of errors would be mostly performed automatically (e.g. 
when one calls 'M-x rgrep'), and that the necessary manual invocations 
of next-error-select-buffer would be infrequent enough. Or that the user 
would be switching between "global" sources of errors at least as often 
as between "local" and "global" ones, we should probably optimize for 
having just one set of commands.

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.