bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer

[Dmitry Gutov]

On 3/7/18 12:33 AM, Juri Linkov wrote:

> I think it would be a natural fit into the next-error framework.  How to
> solve conflicts with other sources of next-error is an open question.
> For example, after running ‘occur’ on the flymake-mode enabled buffer
> next-error should continue navigating ‘occur’ hits.

Right. That creates tradeoffs, which in turn push against the 
flexibility of next-error-find-buffer-function: it's going to more than 
aesthetic choice now.

So I wonder which particular scheme, or schemes, people actually prefer. 
Or which they'd understand more quickly, just by experimenting (that 
might be the best default).

> I guess to cancel
> such navigation is possible in at least three ways: doing window-quit
> on the *Occur* buffer,

For this, next-error-find-buffer-function should be set to 
#'next-error-buffer-on-selected-frame. Or will we have a separate 
predicate function for whether to use the "local" next-error-function?

> or using next-error-select-buffer selecting
> the current buffer (instead of the *Occur* buffer),

That might be too tedious, having to do that for every 
buffer-with-local-errors you switch to and try to edit (and fix 
errors/warnings in).

However, if we special-case the nil value of next-error-last-buffer, it 
might not be so tedious: you switch away from the last Occur/Grep/etc 
buffer with one invocation, and go on editing multiple files.

This is where buffer-local (or window-local) values of 
next-error-last-buffer might bring undesirable behavior: if one of those 
multiple files was another navigation target from an Occur/Grep/etc 
navigation, or if we switch to a window that was the target (in the 
window-local case), the user will need another next-error-select-buffer 
invocation, and they won't know that until their next-error call brings 
them somewhere unexpected (and only winner-mode will help undo that).

There can be other approaches, such as when there's no visible 
global-next-error-capable buffers, and the current one is 
next-error-capable, use it, as long as there are local errors in the 
given direction, and then switch over to the global navigation.

> or re-running flymake
> on the buffer.

That might be annoying: it runs every time a buffer is saved (and even 
right after it's visited if flymake-start-on-flymake-mode is non-nil).

But hey, it can also be a fine approach, as long as 
flymake-start-on-flymake-mode is nil. Recalling that the first idea is 
to only use a global navigation as long as its buffer is visible, let's 
imagine that it's also so in this case. Grep tries very hard to stay 
visible.

So, we run Grep, jump from it to a source file, start editing. Flymake 
runs, shows some warnings. If the user fixes them all, maybe switch back 
to the global navigation automatically; if not, select Grep's window and 
manually navigate to the next error in the list using one of its 
"buttons" (which also sets next-error-last-buffer). And if the 
navigation buffer is not visible, the user can call 
next-error-select-buffer anyway.

This can work well, as long as the user understands what's going on.