Discussion:
next-error use cases
(too old to reply)
Juri Linkov
2018-04-07 21:47:42 UTC
Permalink
Several bug reports such as bug#20489 and bug#30674 revolve around
the uncertainty caused by unclear requirements for the next-error framework.
It would be helpful to identify possible scenarios to get a clearer picture of
what it's supposed to do.

The cornerstone of the whole feature is the function next-error-find-buffer
that returns a next-error capable buffer that defines next-error-function
to navigate to the next location.

Most fallbacks in next-error-find-buffer are fine in case the first condition
fails, but the main question is about the first condition itself: What is the
best default behavior for it? What other useful options it should provide?
What context should be used to select the right next-error-function buffer.

There are several alternatives of what buffer with next-error-function
should be selected after running next-error:

1. last next-error-function used anywhere globally
Pros: context-free, thus easier to understand
Cons: not WYSIWYG, i.e. in some cases produces unexpected results:
for example, after switching to another next-error-function buffer
will still continue the previous navigation from the hidden buffer
with last used next-error-function

2. next-error-function found in the current buffer
Cons: unexpected results when navigation visits another buffer with next-error-function,
e.g. when a ChangeLog file is visited by next-error from the *grep* buffer,
the next next-error should continue visiting grep hits, not ChangeLog entries.
(But when a next-error navigation never visited a next-error-function buffer, then
running `next-error' in a next-error-function buffer should use it unconditionally,
e.g. switching to a *compilation* buffer and running next-error should use it.)

3. next-error-function that visited the current buffer,
i.e. buffer-local value of next-error-last-buffer remembers the last used
next-error-function buffer in each visited buffer, and uses it for the next
next-error.
Cons: unexpected results when the same buffer is visited in different windows
from different next-error-function buffers

4. next-error-function that visited the buffer in the selected window
Pros: window-based logic gives more expected results

5. buffer with next-error-function visible in one of adjacent windows on the same frame
Pros: WYSIWYG
Cons: ambiguous when there are more than one window with next-error-function on the frame

What complicates matter more is that the value of next-error-function might
come from the same buffer where navigation occurs, i.e. unlike these cases
where next-error-function is defined in a special separate buffer:

compilation-next-error-function
xref--next-error-function
occur-next-error
change-log-next-error
diff-next-error

next-error-function can be defined in the same buffer, for example for:

flymake-goto-next-error
flyspell-goto-next-error

where the list of locations comes from the same buffer where next-error
navigates.

So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
Eli Zaretskii
2018-04-08 13:48:03 UTC
Permalink
Date: Sun, 08 Apr 2018 00:47:42 +0300
So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
Define some kind of priority between them? And if two or more
functions have the same priority, ask the user?
Juri Linkov
2018-04-08 19:56:11 UTC
Permalink
Post by Eli Zaretskii
Post by Juri Linkov
So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
Define some kind of priority between them? And if two or more
functions have the same priority, ask the user?
We could try to define priorities by ‘add-function’.
Clément Pit-Claudel
2018-04-08 20:26:59 UTC
Permalink
Post by Juri Linkov
Post by Eli Zaretskii
Post by Juri Linkov
So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
Define some kind of priority between them? And if two or more
functions have the same priority, ask the user?
We could try to define priorities by ‘add-function’.
Or we could query all backends and go to the closest location. It would match with what the user sees on the screen: if I have a flyspell underline followed by a FlyCheck error, it would visit one then the other.
Dmitry Gutov
2018-04-08 20:35:33 UTC
Permalink
Post by Clément Pit-Claudel
Or we could query all backends and go to the closest location. It would match with what the user sees on the screen: if I have a flyspell underline followed by a FlyCheck error, it would visit one then the other.
I'm afraid that won't match the user's intention: if I just run Grep, I
probably want to jump between its results, and not between Flyspell markers.
Stephen Leake
2018-04-10 04:19:39 UTC
Permalink
Post by Dmitry Gutov
Or we could query all backends and go to the closest location. It
would match with what the user sees on the screen: if I have a
flyspell underline followed by a FlyCheck error, it would visit one
then the other.
I'm afraid that won't match the user's intention: if I just run Grep,
I probably want to jump between its results, and not between Flyspell
markers.
+1. I often have several compilation-mode buffers active (one from a
compile, one from a cross-reference tool, one from grep), and I expect
next-error to use the one I last chose.

I chose one by visiting the buffer, and using <ret> to go to an error.

So just be sure the user has a way to indicate which buffer/location
list is "current".
--
-- Stephe
Drew Adams
2018-04-10 14:28:50 UTC
Permalink
Post by Stephen Leake
just be sure the user has a way to indicate which buffer/location
list is "current".
+1. Any "handy DWIM" needs to also give users an easy
way to control things when they want to.

Smart software doesn't think it is smarter than its user
or that she never wants to express her will on the fly.
Eli Zaretskii
2018-04-09 02:24:50 UTC
Permalink
Date: Sun, 8 Apr 2018 16:26:59 -0400
Post by Juri Linkov
We could try to define priorities by ‘add-function’.
Or we could query all backends and go to the closest location. It would match with what the user sees on the screen: if I have a flyspell underline followed by a FlyCheck error, it would visit one then the other.
I don't think "closest location" is a reliable indicator in this
case. next-error exists to go to the next/previous locus, which could
be far away.
Dmitry Gutov
2018-04-08 20:36:37 UTC
Permalink
Post by Eli Zaretskii
Date: Sun, 08 Apr 2018 00:47:42 +0300
So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Eli Zaretskii
2018-04-09 14:48:20 UTC
Permalink
Date: Sun, 8 Apr 2018 23:36:37 +0300
Post by Eli Zaretskii
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Then maybe this problem has no workable solution at all, and we
shouldn't try running all those features from the same command.
Charles A. Roelli
2018-04-09 18:44:42 UTC
Permalink
Date: Mon, 09 Apr 2018 17:48:20 +0300
Post by Dmitry Gutov
Post by Eli Zaretskii
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Then maybe this problem has no workable solution at all, and we
shouldn't try running all those features from the same command.
We could try, but in cases of doubt, ask the user what "next-error"
function he wants to use (and provide some command for actively
switching between them). For example, after calling "next-error" in
some dubious case, the user could be offered a list of functions to
choose between:

- next Compile error from *compile*<dir>
- next Occur result from *scratch*
- next Grep result from *grep*<dir2>
...

There could also be other interfaces to pick a next-error function (a
menu, or something like M-x list-buffers).
Juri Linkov
2018-04-09 20:47:17 UTC
Permalink
Post by Charles A. Roelli
Post by Eli Zaretskii
Post by Dmitry Gutov
Post by Eli Zaretskii
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Then maybe this problem has no workable solution at all, and we
shouldn't try running all those features from the same command.
We could try, but in cases of doubt, ask the user what "next-error"
function he wants to use (and provide some command for actively
switching between them). For example, after calling "next-error" in
some dubious case, the user could be offered a list of functions to
- next Compile error from *compile*<dir>
- next Occur result from *scratch*
- next Grep result from *grep*<dir2>
...
Answering this after every next-error command would be too tedious for users,
and it's not clear how to reduce the frequency of such questions, i.e.
how to detect only dubious cases.
Post by Charles A. Roelli
There could also be other interfaces to pick a next-error function (a
menu, or something like M-x list-buffers).
Recently we created such command with the name ‘next-error-select-buffer’.
Still too inconvenient for users to run this command explicitly.
We need next-error to be more DWIM.
Stephen Leake
2018-04-10 04:24:18 UTC
Permalink
Post by Juri Linkov
Post by Charles A. Roelli
Post by Eli Zaretskii
Post by Dmitry Gutov
Post by Eli Zaretskii
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Then maybe this problem has no workable solution at all, and we
shouldn't try running all those features from the same command.
We could try, but in cases of doubt, ask the user what "next-error"
function he wants to use (and provide some command for actively
switching between them). For example, after calling "next-error" in
some dubious case, the user could be offered a list of functions to
- next Compile error from *compile*<dir>
- next Occur result from *scratch*
- next Grep result from *grep*<dir2>
...
Answering this after every next-error command would be too tedious for users,
and it's not clear how to reduce the frequency of such questions, i.e.
how to detect only dubious cases.
Post by Charles A. Roelli
There could also be other interfaces to pick a next-error function (a
menu, or something like M-x list-buffers).
Recently we created such command with the name ‘next-error-select-buffer’.
Still too inconvenient for users to run this command explicitly.
We need next-error to be more DWIM.
That's what 'compilation-last-buffer' is for; it indicates the buffer
containing the location list that is current.

As long as the user has a convenient way to set that, there's no
problem. In all my current use cases, it is first set by the command
that generated the location list. I can reset it by navigating to a
buffer, and using <return> to goto a location; after that, 'next-error'
continues using that list.
--
-- Stephe
Juri Linkov
2018-04-10 20:06:25 UTC
Permalink
Post by Stephen Leake
Post by Juri Linkov
Recently we created such command with the name ‘next-error-select-buffer’.
Still too inconvenient for users to run this command explicitly.
We need next-error to be more DWIM.
That's what 'compilation-last-buffer' is for; it indicates the buffer
containing the location list that is current.
I don't understand what do you mean by indication? Is it a visual
indication somewhere? I grepped for 'compilation-last-buffer', but in
compile.el 'compilation-last-buffer' is an alias for 'next-error-last-buffer',
and grep.el contains commented out definition whose purpose I don't know:

;;;; TODO --- refine this!!
;; (defcustom grep-use-compilation-buffer t
;; "When non-nil, grep specific commands update `compilation-last-buffer'.
;; This means that standard compile commands like \\[next-error] and \\[compile-goto-error]
;; can be used to navigate between grep matches (the default).
;; Otherwise, the grep specific commands like \\[grep-next-match] must
;; be used to navigate between grep matches."
;; :type 'boolean
;; :group 'grep)
;; override compilation-last-buffer
(defvar grep-last-buffer nil
"The most recent grep buffer.
A grep buffer becomes most recent when you select Grep mode in it.
Notice that using \\[next-error] or \\[compile-goto-error] modifies
`compilation-last-buffer' rather than `grep-last-buffer'.")
Post by Stephen Leake
As long as the user has a convenient way to set that, there's no
problem. In all my current use cases, it is first set by the command
that generated the location list. I can reset it by navigating to a
buffer, and using <return> to goto a location; after that, 'next-error'
continues using that list.
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?
Stephen Leake
2018-04-11 03:26:18 UTC
Permalink
Post by Juri Linkov
Post by Stephen Leake
Post by Juri Linkov
Recently we created such command with the name ‘next-error-select-buffer’.
Still too inconvenient for users to run this command explicitly.
We need next-error to be more DWIM.
That's what 'compilation-last-buffer' is for; it indicates the buffer
containing the location list that is current.
I don't understand what do you mean by indication? Is it a visual
indication somewhere? I grepped for 'compilation-last-buffer', but in
compile.el 'compilation-last-buffer' is an alias for 'next-error-last-buffer',
Use xref: in *scratch*, type compilation-last-buffer, hit M-. (bound to
xref-find-definitions).

That takes you to the definition in compile.el, which is a defalias for
next-error-last-buffer. Invoke M-. on that, it takes to you simple.el:

(defvar next-error-last-buffer nil
"The most recent `next-error' buffer.
A buffer becomes most recent when its compilation, grep, or
similar mode is started, or when it is used with \\[next-error]
or \\[compile-goto-error].")
Post by Juri Linkov
Post by Stephen Leake
As long as the user has a convenient way to set that, there's no
problem. In all my current use cases, it is first set by the command
that generated the location list. I can reset it by navigating to a
buffer, and using <return> to goto a location; after that, 'next-error'
continues using that list.
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.
--
-- Stephe
Dmitry Gutov
2018-04-11 07:29:30 UTC
Permalink
Post by Stephen Leake
Post by Juri Linkov
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.
Juri Linkov
2018-04-11 20:46:24 UTC
Permalink
Post by Stephen Leake
Post by Juri Linkov
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.

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’.

3. Maybe providing only the command next-error-select-buffer to switch
the current navigation is enough even in case when next-error-function
is defined in the same buffer that will be proposed as a candidate.

4. Otherwise, if all else fails, try harder to use visibility as DWIM,
i.e. hide all other navigation windows to start using Flycheck
navigation from the current buffer.
Stephen Leake
2018-04-12 15:31:00 UTC
Permalink
Post by Juri Linkov
Post by Stephen Leake
Post by Juri Linkov
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
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.
Post by Juri Linkov
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
Stephen Leake
2018-04-12 15:25:09 UTC
Permalink
Post by Dmitry Gutov
Post by Stephen Leake
Post by Juri Linkov
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.
Ok. So add a keybinding that says "there is an error under point; use
the list it is part of as the current error list".

Presumably you already have "goto error under point"; that should also
set the current list.

(How do you notice there is an error there, so you know to position point?
a marker in the margin?)

I gather there might be more than one such list in a single buffer, so
compilation-last-buffer is insufficient.

You might be able to extend that; if it is a cons, the car is the
buffer, the car the root list element, or the list type tag, or
something.
--
-- Stephe
Dmitry Gutov
2018-04-12 16:51:48 UTC
Permalink
Post by Stephen Leake
Ok. So add a keybinding that says "there is an error under point; use
the list it is part of as the current error list".
A new key binding or several is an obvious solution. It's also the
clunkiest one (one: key bindings are precious, two: that means extra key
presses to use, and three: extra stuff for the users to memorize).

So of course we can fall back to this approach, but it would be great to
discuss something less obvious first.
Post by Stephen Leake
Presumably you already have "goto error under point"; that should also
set the current list.
(How do you notice there is an error there, so you know to position point?
a marker in the margin?)
The error is not always near point, or even visible in the window. To
get to it, we need a key binding. So, next-error or previous-error
working already would be helpful.
Post by Stephen Leake
I gather there might be more than one such list in a single buffer, so
compilation-last-buffer is insufficient.
That's a problem for another day, I think. Lists in the same buffer can
probably be combined anyway.
Stephen Leake
2018-04-13 16:22:15 UTC
Permalink
Post by Dmitry Gutov
Post by Stephen Leake
Presumably you already have "goto error under point"; that should also
set the current list.
(How do you notice there is an error there, so you know to position point?
a marker in the margin?)
The error is not always near point, or even visible in the window. To
get to it, we need a key binding. So, next-error or previous-error
working already would be helpful.
The command that created the error list can set compilation-last-buffer;
that's what grep does.
--
-- Stephe
Dmitry Gutov
2018-04-13 16:26:12 UTC
Permalink
Post by Stephen Leake
Post by Dmitry Gutov
The error is not always near point, or even visible in the window. To
get to it, we need a key binding. So, next-error or previous-error
working already would be helpful.
The command that created the error list can set compilation-last-buffer;
that's what grep does.
Of course it can. When will it do that? Every time a buffer is opened or
saved? That's when Flymake runs.

What if the user want to continue navigation through their Grep results
instead?

BTW, please take a look at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674, for some previous
discussion.
Dmitry Gutov
2018-04-10 23:06:10 UTC
Permalink
Post by Eli Zaretskii
Date: Sun, 8 Apr 2018 23:36:37 +0300
Post by Eli Zaretskii
Define some kind of priority between them?
I really doubt we can define priorities such that the user will always
want to see the errors of some "kind" before the others.
Then maybe this problem has no workable solution at all, and we
shouldn't try running all those features from the same command.
We already do, though. So far we've come up with a manual switching
solution (see next-error-select-buffer in master), and it's fine to a
degree.

Having Flymake and Flyspell use the same mechanism shows its
inefficiencies, however, so that's what I think this discussion is
mostly about.
Juri Linkov
2018-04-12 20:27:16 UTC
Permalink
Since we removed the rule of visibility of next-error-function buffers
as a criteria for deciding what navigation to use for next-error,
so e.g. next-error in *Occur* or *Diff* that is the current buffer
and a single visible buffer on the frame will still use the last next-error
buffer that might be e.g. *compilation* or *grep* buffer buried long ago,
now we need to support the same way to switch next-error navigation as
already is possible in *compilation* and *grep* by typing RET or ‘C-c C-c’
that sets next-error-last-buffer in next-error-internal among other things.

Tried to pass goto-source commands thru next-error-internal that works fine
for change-log-goto-source but has problems in diff-goto-source
because next-error-internal has no arguments but diff-goto-source
expects ‘other-file’ as an arg.

Another solution is to call a special function like next-error-internal
explicitly from all such goto-source commands. This function could also
set next-error-last-buffer to the current buffer.

Anyway here is the patch that shows the problem with the first solution:

diff --git a/lisp/vc/add-log.el b/lisp/vc/add-log.el
index 175c82f..671f971 100644
--- a/lisp/vc/add-log.el
+++ b/lisp/vc/add-log.el
@@ -471,6 +471,9 @@ change-log-goto-source
comma-separated list. If no suitable tag can be found nearby,
try to visit the file for the change under `point' instead."
(interactive)
+ (next-error-internal))
+
+(defun change-log-goto-source-internal ()
(if (and (eq last-command 'change-log-goto-source)
change-log-find-tail)
(setq change-log-find-tail
@@ -539,7 +542,7 @@ change-log-next-error
;; if we found a place to visit...
(when (looking-at change-log-file-names-re)
(let (change-log-find-window)
- (change-log-goto-source)
+ (change-log-goto-source-internal)
(when change-log-find-window
;; Select window displaying source file.
(select-window change-log-find-window)))))
diff --git a/lisp/vc/diff-mode.el b/lisp/vc/diff-mode.el
index ef13f55..2a70563 100644
--- a/lisp/vc/diff-mode.el
+++ b/lisp/vc/diff-mode.el
@@ -1349,7 +1349,7 @@ diff-next-error
(pop-to-buffer (current-buffer))
(if reset (goto-char (point-min)))
(diff-hunk-next arg)
- (diff-goto-source))
+ (diff-goto-source-internal))

(defvar whitespace-style)
(defvar whitespace-trailing-regexp)
@@ -1874,6 +1874,11 @@ diff-goto-source
;; the old location, and else to the new (i.e. as if reverting).
;; This is a convenient detail when using smerge-diff.
(if event (posn-set-point (event-end event)))
+ (if other-file
+ (diff-goto-source-internal other-file)
+ (next-error-internal)))
+
+(defun diff-goto-source-internal (&optional other-file)
(let ((rev (not (save-excursion (beginning-of-line) (looking-at "[-<]")))))
(pcase-let ((`(,buf ,line-offset ,pos ,src ,_dst ,switched)
(diff-find-source-location other-file rev)))
Eli Zaretskii
2018-04-13 07:45:34 UTC
Permalink
Date: Thu, 12 Apr 2018 23:27:16 +0300
Since we removed the rule of visibility of next-error-function buffers
as a criteria for deciding what navigation to use for next-error,
so e.g. next-error in *Occur* or *Diff* that is the current buffer
and a single visible buffer on the frame will still use the last next-error
buffer that might be e.g. *compilation* or *grep* buffer buried long ago,
now we need to support the same way to switch next-error navigation as
already is possible in *compilation* and *grep* by typing RET or ‘C-c C-c’
that sets next-error-last-buffer in next-error-internal among other things.
Sorry, I don't understand what kind of solution are you proposing in
user terms. Can you please describe what the user should do under the
proposed solution in various cases, such as if they need to invoke
navigation in the current Occur buffer or in a Compilation/Grep
buffer, either shown or not shown?
Juri Linkov
2018-04-13 19:48:59 UTC
Permalink
Post by Eli Zaretskii
Post by Juri Linkov
Since we removed the rule of visibility of next-error-function buffers
as a criteria for deciding what navigation to use for next-error,
so e.g. next-error in *Occur* or *Diff* that is the current buffer
and a single visible buffer on the frame will still use the last next-error
buffer that might be e.g. *compilation* or *grep* buffer buried long ago,
now we need to support the same way to switch next-error navigation as
already is possible in *compilation* and *grep* by typing RET or ‘C-c C-c’
that sets next-error-last-buffer in next-error-internal among other things.
Sorry, I don't understand what kind of solution are you proposing in
user terms. Can you please describe what the user should do under the
proposed solution in various cases, such as if they need to invoke
navigation in the current Occur buffer or in a Compilation/Grep
buffer, either shown or not shown?
I propose to set the global value of next-error-last-buffer after typing
one of the following keybindings in the corresponding buffers:

in *xref* xref-goto-xref: RET
in *Diff* diff-goto-source: RET, C-c C-c, o
in ChangeLogs change-log-goto-source: C-c C-c
in *Occur* occur-mode-goto-occurrence: RET, C-c C-c,
occur-mode-goto-occurrence-other-window: o
occur-mode-display-occurrence: C-o

IOW, doing the same what RET and C-c C-c in *compilation* and *grep* already do.

Here is the final tested patch with these changes:

Loading...