GNU bug report logs - #64230
30.0.50; Ibuffer reports 1 file too many with ibuffer-auto-mode enabled

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stephen Berman <stephen.berman <at> gmx.net>
Subject: bug#64230: closed (Re: bug#64230: 30.0.50; Ibuffer reports 1 file
 too many with ibuffer-auto-mode enabled)
Date: Mon, 11 Sep 2023 14:46:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#64230: 30.0.50; Ibuffer reports 1 file too many with ibuffer-auto-mode enabled

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 64230 <at> debbugs.gnu.org.

-- 
64230: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64230
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 64230-done <at> debbugs.gnu.org
Subject: Re: bug#64230: 30.0.50; Ibuffer reports 1 file too many with
 ibuffer-auto-mode enabled
Date: Mon, 11 Sep 2023 07:44:50 -0700

Version: 30.1

Stephen Berman <stephen.berman <at> gmx.net> writes:

> Done, and pushed as commit ca95e45f7e8.  Thanks.

Thanks, I'm therefore closing the bug.

[Message part 3 (message/rfc822, inline)]

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Ibuffer reports 1 file too many with ibuffer-auto-mode
 enabled
Date: Thu, 22 Jun 2023 19:35:28 +0200

[Message part 4 (text/plain, inline)]

0. emacs -Q
1. Type `M-x' and then TAB to pop up the *Completions* buffer, then type
   `C-g'.
2. Type `M-x ibuffer'.
3. Type `d' on the lines for the buffers *scratch* and *Completions* to
   flag them for deletion.
4. Type `C-c C-a' to enable ibuffer-auto-mode.
5. Type `x' and at the prompt "Really kill 2 buffers? (y or n)" type `y'.
=> The *Ibuffer* lines for  *scratch* and *Completions* are deleted and
   the echo area displays this message: "Operation finished; killed 3
   buffers".

If you change this recipe by omitting step 4, then after the buffer
lines are deleted the message displayed is "Operation finished; killed 2
buffers".

The unexpected message with ibuffer-auto-mode enabled is displayed in
Emacs 27-30 but not in Emacs 26.  With Emacs 27+, on typing `x' at step
5, the buffer *Ibuffer confirmation* pops up and a line for this buffer
immediately appears in the *Ibuffer* display, and this is counted by the
function `ibuffer-map-lines', and on typing `y' not only are the two
flagged buffers deleted, but also *Ibuffer confirmation*, hence "killed
3 buffers".  In contrast, in Emacs 26, the popped up buffer *Ibuffer
confirmation* does not get added to the *Ibuffer* display and thus is
not counted by `ibuffer-map-lines'.

AFAICT, this difference is not due to any ibuffer code changes after
Emacs 26; rather, there appears to be a timing difference with respect
to when Emacs updates the *Ibuffer* display: when I instrument
`ibuffer-update' for Edebug and then type `x' (step 5 above), what
happens in Emacs 26 is that I can confirm with `y', then the flagged
lines are deleted, and only then does Edebug stop the execution so I can
step into `ibuffer-update'; while in Emacs 27+, as soon as I type `x',
Edebug stops execution, i.e., before the flagged lines are deleted.

`ibuffer-update' is called in `ibuffer-auto-update-changed', which is
added to post-command-hook in `ibuffer-auto-mode'.  So it seems that in
Emacs 26 post-command-hook runs or takes effect later than in Emacs 27+.
Whether this is really the case, and if so, what change it is due to, I
haven't determined, and I don't know how restore the Emacs 26 execution
order (or if that's even desirable).  But even if the difference is due
to something else, the message displayed in Emacs 27+ after the deletion
of the *Ibuffer* lines is at least misleading, since it clearly is meant
to refer only to the flagged lines, as in Emacs 26.

In lieu of a real fix, since it is, AFAICS, only the transient buffer
*Ibuffer confirmation* that results in the problematic message, a
workaround is simply to decrement the line count by one when
ibuffer-auto-mode is enabled, as in the the attached patch (which also
takes the opportunity to wrap an overlong line in `ibuffer-map-lines').


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.17.6) of 2023-06-22 built on strobelfs
Repository revision: a23a09a82fc59402f1f7c23a46c65fc7001eecdf
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Linux From Scratch r11.3-65

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

[Message part 5 (text/x-patch, attachment)]

Previous Next

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