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