From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org
Subject: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented
Date: Fri, 22 May 2020 02:57:37 +0300 [thread overview]
Message-ID: <facedf6f-544d-f2d5-4a01-727c99d65dc2@yandex.ru> (raw)
In-Reply-To: <87v9kr8t1s.fsf@mail.linkov.net>
[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]
On 20.05.2020 01:21, Juri Linkov wrote:
>>> Another variant would be
>>> to add an optional choice to the existing option that allows to restore
>>> the old behavior and doesn't affect the current behavior in any way.
>>
>> FWIW, I'd consider that more of a documentation change.
>>
>> More importantly, and certainly only for Emacs 28, Juri could you remind me
>> what we'll be losing by removing the case no. 2 from
>> next-error-find-buffer?
>
> It is used to handle such cases when navigating one next-error list
> visits a buffer that contains another next-error list - visiting
> such buffer should not switch the navigation, it should continue
> the initial navigation.
Didn't we fix changelog-mode so this doesn't happen anymore? I think as
long as file major modes don't set next-error-last-buffer (and minor
modes either, on initialization), we should be safe.
Can you reproduce a problematic scenario with the attached patch?
> But I'm not proud of the case no. 2, so you can drop it :)
>
> Or better move it to a separate function and provide this function
> as an option in next-error-find-buffer-function.
Patch attached. Comments welcome.
>> The ability to switch to an arbitrary Grep buffer and start using it with
>> 'M-x next-error'? E.g. if there are several of them. That's more of
>> a backward compatibility concern, right? Or do you have scenarios in
>> mind where this will really save on keystrokes?
>
> The ability to visit an arbitrary Grep buffer and use 'next-error' in it
> to switch navigation should always work as the most reliable and implicit
> way to switch navigation. This is the case no. 3 in next-error-find-buffer.
Not if there are, say, two Compilation buffers (or Grep and Occur, etc),
and you switch to the least recently used one, and press M-g n.
It's probably fine, though.
>> On another note, perhaps we could add a message to next-error-select-buffer
>> that would be shown if we suspect this command will not have the expected
>> result for the user.
>
> Or maybe ask the user using the minibuffer to resolve ambiguity.
Resolve it how? I think we can safely guess their intention, it's just
not trivial to execute it.
Anyway, this problem should go away with the attached patch.
[-- Attachment #2: next-error-extract-case-2.diff --]
[-- Type: text/x-patch, Size: 3916 bytes --]
diff --git a/lisp/simple.el b/lisp/simple.el
index 111afa69d1..31d6cbcef2 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -211,6 +211,8 @@ next-error-find-buffer-function
:type '(choice (const :tag "No default" ignore)
(const :tag "Single next-error capable buffer on selected frame"
next-error-buffer-on-selected-frame)
+ (const :tag "Current buffer if next-error capable and outside navigation"
+ next-error-buffer-try-current-outside-navigation)
(function :tag "Other function"))
:group 'next-error
:version "27.1")
@@ -240,6 +242,21 @@ next-error-buffer-on-selected-frame
(if (eq (length window-buffers) 1)
(car window-buffers))))
+(defun next-error-buffer-try-current-outside-navigation (&optional
+ avoid-current
+ extra-test-inclusive
+ extra-test-exclusive)
+ "Maybe Return current buffer if it's next-error capable.
+But return nil if we navigated to the current buffer by the means
+of `next-error' command."
+ ;; Check that next-error-buffer has no buffer-local value
+ ;; (i.e. never navigated to the current buffer from another),
+ ;; and the current buffer is a `next-error' capable buffer.
+ (if (and (not (local-variable-p 'next-error-buffer))
+ (next-error-buffer-p (current-buffer) avoid-current
+ extra-test-inclusive extra-test-exclusive))
+ (current-buffer)))
+
(defun next-error-find-buffer (&optional avoid-current
extra-test-inclusive
extra-test-exclusive)
@@ -260,24 +277,16 @@ next-error-find-buffer
(funcall next-error-find-buffer-function avoid-current
extra-test-inclusive
extra-test-exclusive)
- ;; 2. If next-error-buffer has no buffer-local value
- ;; (i.e. never navigated to the current buffer from another),
- ;; and the current buffer is a `next-error' capable buffer,
- ;; use it unconditionally, so next-error will always use it.
- (if (and (not (local-variable-p 'next-error-buffer))
- (next-error-buffer-p (current-buffer) avoid-current
- extra-test-inclusive extra-test-exclusive))
- (current-buffer))
- ;; 3. If next-error-last-buffer is an acceptable buffer, use that.
+ ;; 2. If next-error-last-buffer is an acceptable buffer, use that.
(if (and next-error-last-buffer
(next-error-buffer-p next-error-last-buffer avoid-current
extra-test-inclusive extra-test-exclusive))
next-error-last-buffer)
- ;; 4. If the current buffer is acceptable, choose it.
+ ;; 3. If the current buffer is acceptable, choose it.
(if (next-error-buffer-p (current-buffer) avoid-current
extra-test-inclusive extra-test-exclusive)
(current-buffer))
- ;; 5. Look for any acceptable buffer.
+ ;; 4. Look for any acceptable buffer.
(let ((buffers (buffer-list)))
(while (and buffers
(not (next-error-buffer-p
@@ -285,7 +294,7 @@ next-error-find-buffer
extra-test-inclusive extra-test-exclusive)))
(setq buffers (cdr buffers)))
(car buffers))
- ;; 6. Use the current buffer as a last resort if it qualifies,
+ ;; 5. Use the current buffer as a last resort if it qualifies,
;; even despite AVOID-CURRENT.
(and avoid-current
(next-error-buffer-p (current-buffer) nil
@@ -293,7 +302,7 @@ next-error-find-buffer
(progn
(message "This is the only buffer with error message locations")
(current-buffer)))
- ;; 7. Give up.
+ ;; 6. Give up.
(error "No buffers contain error message locations")))
(defun next-error (&optional arg reset)
next prev parent reply other threads:[~2020-05-21 23:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 1:51 bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Trevor Spiteri
2020-04-28 11:37 ` Trevor Spiteri
2020-04-28 23:40 ` Juri Linkov
2020-04-29 0:13 ` Trevor Spiteri
2020-04-29 20:38 ` Juri Linkov
2020-04-29 22:40 ` Trevor Spiteri
2020-04-30 20:14 ` Juri Linkov
2020-04-30 23:18 ` Trevor Spiteri
2020-05-02 23:38 ` Juri Linkov
2020-05-03 2:40 ` Eli Zaretskii
2020-05-03 22:36 ` Juri Linkov
2020-05-19 1:48 ` Dmitry Gutov
2020-05-19 22:21 ` Juri Linkov
2020-05-21 23:57 ` Dmitry Gutov [this message]
2020-05-23 22:24 ` Juri Linkov
2020-05-23 23:30 ` Dmitry Gutov
2020-05-24 21:48 ` Juri Linkov
2020-05-25 1:58 ` Dmitry Gutov
2020-05-25 15:17 ` Eli Zaretskii
2020-05-25 23:17 ` Dmitry Gutov
2020-05-26 16:06 ` Eli Zaretskii
2020-05-26 16:20 ` Dmitry Gutov
2020-05-26 16:33 ` Eli Zaretskii
2020-05-26 20:39 ` Dmitry Gutov
2020-05-27 19:18 ` Dmitry Gutov
2020-05-30 22:29 ` Juri Linkov
2020-06-10 23:03 ` Juri Linkov
2020-06-10 23:28 ` Dmitry Gutov
2020-06-11 13:11 ` Eli Zaretskii
2020-06-11 22:39 ` Juri Linkov
2020-06-12 7:06 ` Eli Zaretskii
2020-06-13 22:53 ` Juri Linkov
2020-06-14 23:17 ` Juri Linkov
2020-05-28 23:07 ` Dmitry Gutov
2020-06-01 22:41 ` Juri Linkov
2020-06-01 23:04 ` Dmitry Gutov
2020-06-10 23:05 ` Juri Linkov
2020-06-10 23:32 ` Dmitry Gutov
2020-06-11 22:43 ` Juri Linkov
2020-06-14 11:50 ` Dmitry Gutov
2020-06-14 23:15 ` Juri Linkov
2020-06-15 7:58 ` Dmitry Gutov
2020-06-24 23:38 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=facedf6f-544d-f2d5-4a01-727c99d65dc2@yandex.ru \
--to=dgutov@yandex.ru \
--cc=40919@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=tspiteri@ieee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).