From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Francesco =?UTF-8?Q?Potort=C3=AC?= Newsgroups: gmane.emacs.bugs Subject: bug#46463: 27.1; rmailout glitch Date: Mon, 15 Feb 2021 17:19:19 +0100 Message-ID: References: <83y2fscmii.fsf@gnu.org> <83pn119wel.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8936"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46463@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 15 17:20:20 2021 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 1lBgbk-0002F9-QN for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Feb 2021 17:20:20 +0100 Original-Received: from localhost ([::1]:51524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBgbj-0003Lb-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Feb 2021 11:20:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBgbS-0003KJ-8R for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 11:20:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55276) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lBgbS-0008Kr-0P for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 11:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lBgbR-0004hm-RP for bug-gnu-emacs@gnu.org; Mon, 15 Feb 2021 11:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Francesco =?UTF-8?Q?Potort=C3=AC?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Feb 2021 16:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46463 X-GNU-PR-Package: emacs Original-Received: via spool by 46463-submit@debbugs.gnu.org id=B46463.161340596418035 (code B ref 46463); Mon, 15 Feb 2021 16:20:01 +0000 Original-Received: (at 46463) by debbugs.gnu.org; 15 Feb 2021 16:19:24 +0000 Original-Received: from localhost ([127.0.0.1]:38589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBgap-0004go-Je for submit@debbugs.gnu.org; Mon, 15 Feb 2021 11:19:23 -0500 Original-Received: from smtp-clients1.isti.cnr.it ([146.48.28.36]:51972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lBgao-0004gf-Ce for 46463@debbugs.gnu.org; Mon, 15 Feb 2021 11:19:22 -0500 Original-Received: from tucano.isti.cnr.it (tucano.isti.cnr.it [146.48.81.102]) (Authenticated sender: pot) by smtp-clients1.isti.cnr.it (Postfix) with ESMTPSA id 7F0AEB0820; Mon, 15 Feb 2021 17:19:20 +0100 (CET) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.0 at smtp-out.isti.cnr.it Original-Received: from pot by tucano.isti.cnr.it with local (Exim 4.94) (envelope-from ) id 1lBgam-000EKU-6z; Mon, 15 Feb 2021 17:19:20 +0100 In-Reply-To: <83pn119wel.fsf@gnu.org> (eliz@gnu.org) X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 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" Xref: news.gmane.io gmane.emacs.bugs:200070 Archived-At: >> From: Francesco Potort́ >> Date: Mon, 15 Feb 2021 12:26:09 +0100 >> Cc: 46463@debbugs.gnu.org >> >> emacs -Q -nw >> M-x load-library RET /tmp/bug.el RET >> C-u M-x rmail RET /tmp/RMAILbug RET <-- looking at message #3 >> C-d <-- looking at message #2 >> o /tmp/a RET <-- looking at message #3 >> >> After the last command I should get a message saying that no more >> undeleted messages are there, and be looking at message #2, however I >> get no message and I am looking a message #3. > >So the problem is that you don't get the message about no following >undeleted message? Or is something else the problem? >Regarding the lack of message, I'm not sure this is a bug: since you >set rmail-output-reset-deleted-flag non-nil, Rmail no longer tries to >get to the next undeleted message, it instead gets to the next >message, whether deleted or not. > The doc string of rmail-output says: > > Optional prefix argument COUNT (default 1) says to output that > many consecutive messages, starting with the current one (ignoring > deleted messages, unless `rmail-output-reset-deleted-flag' is > non-nil). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^^ Hm. This is not the semantics I had intended when I first suggested adding that flag. In my proposed implementation (which was rejected probably because it did not cover all cases, I do not recall for sure) the only effect of rmail-output-reset-deleted-flag was on the output file, it did not change anything on the current file or the behaviour of the commands. Since current message #2 is being deleted, and the subsequent message $3 is already deleted, I expect the same that happens when pressing 'd' on message #2: 1) get a message saying that there is no further undeleted message 2) stay on the same message Instead, the current message #2 is deleted and I am shown message #3. This should happen only if message #3 was not deleted. What the flag should do is to reset the flag when writing the message to the output file (it should not affect the flag on the original mail file). In this case, since rmail-delete-after-output is t, 1) and 2) should happen. In fact, they do happen if rmail-output-reset-deleted-flag is nil. >Why it is a problem for you that Rmail goes to the very next message >in this situation? Because I want 'o' to work the same (as far as the current mail file is regarded) independent of the setting of rmail-output-reset-deleted-flag. The only difference in behaviour should be whether the deleted flag is set in the message copy that goes in the output file.