GNU bug report logs - #47050
28.0.50; [PATCH] `next-error-find-buffer' does things in the wrong order

Previous Next

Package: emacs;

Reported by: Nick Dokos <ndokos <at> gmail.com>

Date: Wed, 10 Mar 2021 15:06:02 UTC

Severity: normal

Tags: moreinfo, patch

Found in version 28.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47050 in the body.
You can then email your comments to 47050 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#47050; Package emacs. (Wed, 10 Mar 2021 15:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nick Dokos <ndokos <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 10 Mar 2021 15:06:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nick Dokos <ndokos <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50;
 [PATCH] `next-error-find-buffer' does things in the wrong  order
Date: Tue, 09 Mar 2021 14:37:49 -0500
The doc for `next-error' says:

<quote>
C-x ` normally uses the most recently started
compilation, grep, or occur buffer.  It can also operate on any
buffer with output from the M-x compile, M-x grep commands, or,
more generally, on any buffer in Compilation mode or with
Compilation Minor mode enabled, or any buffer in which
‘next-error-function’ is bound to an appropriate function.
To specify use of a particular buffer for error messages, type
C-x ` in that buffer.  You can also use the command
‘next-error-select-buffer’ to select the buffer to use for the subsequent
invocation of ‘next-error’.
</quote>

I interpreted that to mean that if I create e.g. two `grep' buffers and
rename them uniquely to `*grep*<2>' and `*grep<3>', then switching
to one or the other of them and calling `next-error' would use the hits
from that buffer. However it always uses the hits from the last-used grep
buffer and I have to change that explicitly, by calling
`next-error-select-buffer', instead of letting the current buffer
determine it.

The problem is caused by `next-error-find-buffer' which does things in
the (IMO) wrong order: it first checks for next-error-last-buffer and
then it checks for the current buffer.

Here is a patch to reverse the order:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/simple.el b/lisp/simple.el
index f8050091d5..8796b612cc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -298,15 +298,15 @@ next-error-find-buffer
    (funcall next-error-find-buffer-function avoid-current
                                             extra-test-inclusive
                                             extra-test-exclusive)
-   ;; 2. If next-error-last-buffer is an acceptable buffer, use that.
+   ;; 2. 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))
+   ;; 3. 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)
-   ;; 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))
    ;; 4. Look for any acceptable buffer.
    (let ((buffers (buffer-list)))
      (while (and buffers
--8<---------------cut here---------------end--------------->8---


This arose in a question on the Emacs SE:

https://emacs.stackexchange.com/questions/63807/is-there-a-way-to-get-two-separate-next-error-lists-so-i-can-bind-them-to-two-di

---------------------------------------------------------------------------


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.25, cairo version 1.16.0)
 of 2021-03-07 built on pierrot.dokosmarshall.org
Repository revision: 997142a4ddc98158cb71bdcef58df5a24f9a9a5c
Repository branch: comint-send-input-timeout
Windowing system distributor 'Fedora Project', version 11.0.12010000
System Description: Fedora 33 (Thirty Three)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE
XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x thingatpt
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 54100 9914)
 (symbols 48 6694 1)
 (strings 32 18784 1955)
 (string-bytes 1 617945)
 (vectors 16 13356)
 (vector-slots 8 176023 12810)
 (floats 8 21 50)
 (intervals 56 235 0)
 (buffers 992 12))

-- 
Nick



-- 
Nick







Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47050; Package emacs. (Thu, 11 Mar 2021 19:25:01 GMT) Full text and rfc822 format available.

Message #8 received at 47050 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Nick Dokos <ndokos <at> gmail.com>
Cc: 47050 <at> debbugs.gnu.org
Subject: Re: bug#47050: 28.0.50; [PATCH] `next-error-find-buffer' does
 things in the wrong  order
Date: Thu, 11 Mar 2021 21:23:54 +0200
> The doc for `next-error' says:
> ...
> I interpreted that to mean that if I create e.g. two `grep' buffers and
> rename them uniquely to `*grep*<2>' and `*grep<3>', then switching
> to one or the other of them and calling `next-error' would use the hits
> from that buffer. However it always uses the hits from the last-used grep
> buffer and I have to change that explicitly, by calling
> `next-error-select-buffer', instead of letting the current buffer
> determine it.
>
> The problem is caused by `next-error-find-buffer' which does things in
> the (IMO) wrong order: it first checks for next-error-last-buffer and
> then it checks for the current buffer.

Please try the following use case:

0. emacs -Q
1. call `grep' (anywhere) that displays the *grep* buffer
2. switch to the the *grep* buffer
3. in the *grep* buffer call `occur' that displays the *Occur* buffer
   with matches from the *grep* buffer
4. switch to the *Occur* buffer
5. type C-x ` (`next-error') in the *Occur* buffer
6. type C-x ` again - it continues visiting hits from the *Occur* buffer

But with your patch the second C-x ` will stop visiting hits
from the *Occur* buffer.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47050; Package emacs. (Mon, 15 Mar 2021 17:11:04 GMT) Full text and rfc822 format available.

Message #11 received at 47050 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Nick Dokos <ndokos <at> gmail.com>
Cc: 47050 <at> debbugs.gnu.org
Subject: Re: bug#47050: 28.0.50; [PATCH] `next-error-find-buffer' does
 things in the wrong  order
Date: Mon, 15 Mar 2021 19:07:12 +0200
> The doc for `next-error' says:
> ...
> I interpreted that to mean that if I create e.g. two `grep' buffers and
> rename them uniquely to `*grep*<2>' and `*grep<3>', then switching
> to one or the other of them and calling `next-error' would use the hits
> from that buffer. However it always uses the hits from the last-used grep
> buffer and I have to change that explicitly, by calling
> `next-error-select-buffer', instead of letting the current buffer
> determine it.

Please try to customize 'next-error-find-buffer-function' to this value:

  (const :tag "Current buffer if next-error capable and outside navigation"
         next-error-buffer-unnavigated-current)

It provides the behavior that you described.




Added tag(s) moreinfo. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Sun, 04 Apr 2021 00:31:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47050; Package emacs. (Wed, 12 May 2021 19:03:01 GMT) Full text and rfc822 format available.

Message #16 received at 47050 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: Nick Dokos <ndokos <at> gmail.com>, 47050 <at> debbugs.gnu.org
Subject: Re: bug#47050: 28.0.50; [PATCH] `next-error-find-buffer' does
 things in the wrong  order
Date: Wed, 12 May 2021 21:01:57 +0200
Juri Linkov <juri <at> linkov.net> writes:

> Please try to customize 'next-error-find-buffer-function' to this value:
>
>   (const :tag "Current buffer if next-error capable and outside navigation"
>          next-error-buffer-unnavigated-current)
>
> It provides the behavior that you described.

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 47050 <at> debbugs.gnu.org and Nick Dokos <ndokos <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 12 May 2021 19:03:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 10 Jun 2021 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 333 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.