* bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
@ 2018-03-02 1:15 Dmitry Gutov
2018-03-06 22:33 ` Juri Linkov
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Gutov @ 2018-03-02 1:15 UTC (permalink / raw)
To: 30674; +Cc: juri
X-Debbugs-CC: joaotavora@gmail.com
X-Debbugs-CC: juri@linkov.net
Considering the names and docstrings of next-error and previous-error, I
think it's quite reasonable to expect to be able to navigate the Flymake
diagnostics with them.
João, was there a particular reason you decided against it? Can we
improve next-error somehow, for this to become more appealing?
Juri, any thoughts? The foremost apparent difficulty is that virtually
any file-editing buffer can become a next-error capable buffer. Would
opening a new file interactively (with flymake-mode being turned on)
automatically change next-error-last-buffer? Would it change after
save-buffer (after which diagnostics are normally refreshed)?
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
2018-03-02 1:15 bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer Dmitry Gutov
@ 2018-03-06 22:33 ` Juri Linkov
2018-03-13 0:43 ` Dmitry Gutov
0 siblings, 1 reply; 4+ messages in thread
From: Juri Linkov @ 2018-03-06 22:33 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30674
> Considering the names and docstrings of next-error and previous-error, I
> think it's quite reasonable to expect to be able to navigate the Flymake
> diagnostics with them.
>
> João, was there a particular reason you decided against it? Can we
> improve next-error somehow, for this to become more appealing?
>
> Juri, any thoughts? The foremost apparent difficulty is that virtually
> any file-editing buffer can become a next-error capable buffer. Would
> opening a new file interactively (with flymake-mode being turned on)
> automatically change next-error-last-buffer? Would it change after
> save-buffer (after which diagnostics are normally refreshed)?
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. I guess to cancel
such navigation is possible in at least three ways: doing window-quit
on the *Occur* buffer, or using next-error-select-buffer selecting
the current buffer (instead of the *Occur* buffer), or re-running flymake
on the buffer.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
2018-03-06 22:33 ` Juri Linkov
@ 2018-03-13 0:43 ` Dmitry Gutov
2018-03-13 22:23 ` Juri Linkov
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Gutov @ 2018-03-13 0:43 UTC (permalink / raw)
To: Juri Linkov; +Cc: 30674
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
2018-03-13 0:43 ` Dmitry Gutov
@ 2018-03-13 22:23 ` Juri Linkov
0 siblings, 0 replies; 4+ messages in thread
From: Juri Linkov @ 2018-03-13 22:23 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30674
>> 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.
Yes, and in this case you can see the clarity and predictability of
this option: when the *Occur* buffer is visible on the selected frame,
next-error will navigate the occur results as the user will expect.
Hiding the window with the *Occur* buffer will switch navigation
to Flymake warnings in the current buffer. This is what can be called
WYSIWYG.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-03-13 22:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-02 1:15 bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer Dmitry Gutov
2018-03-06 22:33 ` Juri Linkov
2018-03-13 0:43 ` Dmitry Gutov
2018-03-13 22:23 ` Juri Linkov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.