From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#64230: 30.0.50; Ibuffer reports 1 file too many with ibuffer-auto-mode enabled Date: Wed, 13 Sep 2023 20:51:47 +0200 Message-ID: <87il8d9a9o.fsf@gmx.net> References: <874jmzo0wv.fsf@gmx.net> <87cyyox070.fsf@gmx.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38118"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 64230@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 13 20:53:17 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qgUzE-0009i7-KW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Sep 2023 20:53:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgUyx-0002ja-RI; Wed, 13 Sep 2023 14:52:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgUyv-0002j9-SL for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 14:52:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgUyv-0003yV-KD for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 14:52:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qgUz0-0004wS-6X for bug-gnu-emacs@gnu.org; Wed, 13 Sep 2023 14:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Sep 2023 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64230 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 64230-submit@debbugs.gnu.org id=B64230.169463112718909 (code B ref 64230); Wed, 13 Sep 2023 18:53:02 +0000 Original-Received: (at 64230) by debbugs.gnu.org; 13 Sep 2023 18:52:07 +0000 Original-Received: from localhost ([127.0.0.1]:36025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgUy6-0004uv-Al for submit@debbugs.gnu.org; Wed, 13 Sep 2023 14:52:06 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:41455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qgUy0-0004u8-0z for 64230@debbugs.gnu.org; Wed, 13 Sep 2023 14:52:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1694631107; x=1695235907; i=stephen.berman@gmx.net; bh=YfkfZDPnd6hjXw0Qx3lhtZWfIiVN/KM7UwKKj4MQcSU=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=FFSTwR+rnsVeQY3RKCDMbyJ+VnwIhb6ZHklC9P1TePXj2G68ZeUY+f7sy6skyXQAHo8FmYLj140 e/fGWB9eAnTohw9tzPMEjRBKeQA4/ujXtukfSU9Y0ebhh9+lEW8AJErno1kfraf93bNli5c3MjLGc SUN5DBX9d/Vj6E7/DgcIQ5xJ5qGXnryYMhKKYbZhJvuxOwog0Z+ZarKvdEvWXY/6j9+31Nw5OwN46 Gi+LakVLaukoLnpsLpi49T+P69T7wHBOlZj5M7r5kikdZeJR1mjh/hcX9jrMjayBuzBuwQRoDThNk Cvpew6Gsgpata2Ay23MhChBZoB1FnNDIRBzQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from strobelfs2 ([94.134.196.129]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M7K3Y-1qoDfj2sUG-007oSZ; Wed, 13 Sep 2023 20:51:47 +0200 In-Reply-To: <87cyyox070.fsf@gmx.net> (Stephen Berman's message of "Mon, 11 Sep 2023 16:18:43 +0200") X-Provags-ID: V03:K1:HAg4+3NzbwOYc7tC3HKB60LVRazFCkgsphmTZfEFyYum4FlhFHx tMvA/f2lfTfdVr08Mev8dp0gRyYfSGEdC7ZSGCVMuAgdvjm+No6hGIOTCHOfwOq1ctsx/P6 yvBo81isoN5j7iQwDpOSt4u+YArhV/umkauXr1e8aEfcDBW20qnOhmMLZwTSK2LnT68DAV2 L2FuihDvjEQTRYtkquwag== UI-OutboundReport: notjunk:1;M01:P0:/i9PvlNnQ5k=;6CcTW9+Bcyb78MLMV17W+TjqQ4b 3MXACYmc3ceKchu2LsfmuEYMvFeusAsRqjcb/P7SJLKx9E0xsrTbcl8z9nNu6mg2LO+TpEjro NWcGM2yS/y9SCxfICN2KcPuwZlMyQe/6SY5BrBTMHc1yqrK3j36cdi4a2t3iAGdZQ3Er9PwdJ uhjJNqGWMxbrEWrGMMIhhcTaMcEctMPRgHhWeWm8iMLo/KZWfFZ/Nkq8Kkll39sappRnZogDm eetLAoTOqRkQuns3vDZQomkPCST3w1m3gWB+cG1p3egNcRV9pixSm957/2YV45iQg3JWiuBkp HYkjT1TE2y52oniimG9F8fMIFRCx0DxSGZBKyCQCnoyoz3Y3ufxbuBl+ShylScx4BJt9633OJ tUFJmTAiYJn7j/GjM/Fj5QC43/XTxneaIvUczCqoN3hs0ogfD57bTdabRuc3USwRWkG9vcurA ytQgdeeau/xGsBxjJYzCpI9mK0R0iWb4HssGzi/Ln2DBiTOCXzp8l6w7zKA0bu8zjidWhvF3U CKg3Im0qnJHO/n8ll0+8pe6LBtW3hUo6KubE9A5BpG3aUDVvAtTRuMTB8qnNAU46pThp7L3sD 7qSkOhKLCRzXpNAIDT2ihG4xumdYUdBWgz4gaNEGz5GEKXEHPmTis0cykRJYalWWh5lQmZL9K 4euACGFNL5x68qq/kRu0bdY9vg+3SSbDzNO8hY2lHtgd069AvBmuNNpRUM3Uc6bxoMNAAYnnj u3DeZoYK5OCtGySxZWBtg3f8nJXeOTja2EjnHvKXqtJ1zCKSmmtb5KoBhHr6egoZmGRBIHhL X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270346 Archived-At: --=-=-= Content-Type: text/plain On Mon, 11 Sep 2023 16:18:43 +0200 Stephen Berman wrote: > On Sun, 10 Sep 2023 07:11:07 -0700 Stefan Kangas wrote: > >> Stephen Berman writes: >> >>> 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'). >> >> Your analysis and patch makes sense to me. Please install, but add a >> brief comment explaining why we do that decrement there. > > Done, and pushed as commit ca95e45f7e8. Thanks. Unfortunately, I didn't test that commit adequately before pushing it and have found two regressions it introduced: - If you delete exactly one buffer in Ibuffer with ibuffer-auto-mode enabled, it now emits the message "Operation finished; killed 0 buffers". - If you delete two buffers in Ibuffer with ibuffer-auto-mode enabled and with ibuffer-expert non-nil, it emits the message "Operation finished; killed 1 buffers" (in general, one less than the number of buffers deleted). The first attached patch fixes these regressions while retaining the improvement in ca95e45f7e8. While debugging I noticed two unrelated infelicities in the Ibuffer feedback: - The message reporting deletion of one buffer is grammatically incorrect: "killed 1 buffers". - If you type `x' in an Ibuffer buffer containing no marked buffer lines and with point not on one of the buffer lines (e.g. at (point-min) or (point-max)), you are prompted with "Really kill buffer *Ibuffer*? (y or n)" and if you type `y', the resulting message is "Operation finished; killed 0 buffers". This statement is correct, since no buffer was killed (without the first patch, the message is nonsensical: "killed -1 buffers"), but then Ibuffer appears to be ignoring the user's response to its prompt. However, I think the prompt itself is a mistake, and instead, Ibuffer should point out that there's no buffer on the current line and do nothing else (but again, only when there are no marked buffer lines.) The second attached patch fixes these problems (to see the effect I had to bootstrap; just regenerating ibuffer-loaddefs.el and loaddefs.el was insufficient). Should I install both patches? I've tested all combinations of deleting just one or more than buffer with ibuffer-auto-mode disabled and enabled and ibuffer-expert nil and non-nil, but perhaps I've again overlooked something, so I'll wait for a go-ahead. Also, since the second patch is strictly unrelated to the original bug report, a new bug report for it might be preferred. Steve Berman --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: ibuffer-map-lines patch diff --git a/lisp/ibuffer.el b/lisp/ibuffer.el index b5a7f2d04e0..c30c38a90fd 100644 --- a/lisp/ibuffer.el +++ b/lisp/ibuffer.el @@ -1898,14 +1898,17 @@ ibuffer-map-lines (t (cl-incf ibuffer-map-lines-count) (forward-line 1))))) - ;; With `ibuffer-auto-mode' enabled, the preceding loop - ;; counts the automatically popped up (and hence not - ;; user-marked) buffer "*Ibuffer confirmation*". Since - ;; Ibuffer reports how many user-marked buffers were acted - ;; upon, and in this case the reported count would be too - ;; high by one, we decrement the count to avoid the + ;; With `ibuffer-auto-mode' enabled, `ibuffer-expert' + ;; non-nil and more than one marked buffer lines, the + ;; preceding loop counts the automatically popped up (and + ;; hence not user-marked) buffer "*Ibuffer confirmation*". + ;; Since Ibuffer reports how many marked buffers lines were + ;; acted upon, and in this case the reported count would be + ;; too high by one, we decrement the count to avoid the ;; confusing message (see bug#64230). - (if (and (featurep 'ibuf-ext) ibuffer-auto-mode) + (if (and (featurep 'ibuf-ext) ibuffer-auto-mode + (> ibuffer-map-lines-count 1) + (not ibuffer-expert)) (1- ibuffer-map-lines-count) ibuffer-map-lines-count)) (progn --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: define-ibuffer-op patch diff --git a/lisp/ibuf-macs.el b/lisp/ibuf-macs.el index c38dfefe0c5..36616389f99 100644 --- a/lisp/ibuf-macs.el +++ b/lisp/ibuf-macs.el @@ -230,6 +230,9 @@ define-ibuffer-op (_ 'ibuffer-marked-buffer-names))))) (when (null marked-names) + (cl-assert (get-text-property (line-beginning-position) + 'ibuffer-properties) + nil "No buffer on this line") (setq marked-names (list (buffer-name (ibuffer-current-buffer)))) (ibuffer-set-mark ,(pcase mark (:deletion @@ -243,7 +246,9 @@ define-ibuffer-op ()) (and after `(,after)) ; post-operation form. `((ibuffer-redisplay t) - (message ,(concat "Operation finished; " opstring " %s buffers") count)))) + (message ,(concat "Operation finished; " opstring + " %s %s") + count (ngettext "buffer" "buffers" count))))) (inner-body (if complex `(progn ,@body) `(progn --=-=-=--