all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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)

  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

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