GNU bug report logs - #46463
27.1; rmailout glitch

Previous Next

To reply to this bug, email your comments to 46463 AT debbugs.gnu.org.

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

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

From: Francesco Potortì <pot <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; rmailout glitch
Date: Fri, 12 Feb 2021 16:10:04 +0100

Using the latest versions from trunk as of 11 February:

rmailsum
rmailout
rmailmm
rmail
rmailedit

- run rmail on a mail file with N messages (N>1)
- delete message N
- go to message N-1 and press 'o' to output it to a different mail
  file: a message says that no undeleted messages exist and you still
  see message N-1 (which is correct)
- (setq rmail-output-reset-deleted-flag t
  	rmail-delete-after-output t)
- undelete message N-1
- press 'o': no message is displayed and you see (deleted) message N

If only rmail-delete-after-output is set, I can't see the problem

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Sat, 13 Feb 2021 12:03:49 +0200

> From: Francesco Potortì <pot <at> gnu.org>
> Date: Fri, 12 Feb 2021 16:10:04 +0100
> 
> Using the latest versions from trunk as of 11 February:
> 
> rmailsum
> rmailout
> rmailmm
> rmail
> rmailedit
> 
> - run rmail on a mail file with N messages (N>1)
> - delete message N
> - go to message N-1 and press 'o' to output it to a different mail
>   file: a message says that no undeleted messages exist and you still
>   see message N-1 (which is correct)
> - (setq rmail-output-reset-deleted-flag t
>   	rmail-delete-after-output t)
> - undelete message N-1
> - press 'o': no message is displayed and you see (deleted) message N

I cannot reproduce this.  Is this in "emacs -Q"?  If so, could you
please show a complete recipe, starting from "emacs -Q", and
preferably excluding any parts that are not needed for showing the
issue?

Also, the Subject says "27.1"; if this problem exists in Emacs 27.1 as
well, please tell, as that could change the priority of handling the
issue, given that Emacs 27.2 is in the last stages of pretesting.

Thanks.

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

From: Francesco Potortì <pot <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Sat, 13 Feb 2021 11:21:36 +0100

>> From: Francesco Potortì <pot <at> gnu.org>
>> Date: Fri, 12 Feb 2021 16:10:04 +0100
>> 
>> Using the latest versions from trunk as of 11 February:
>> 
>> rmailsum
>> rmailout
>> rmailmm
>> rmail
>> rmailedit
>> 
>> - run rmail on a mail file with N messages (N>1)
>> - delete message N
>> - go to message N-1 and press 'o' to output it to a different mail
>>   file: a message says that no undeleted messages exist and you still
>>   see message N-1 (which is correct)
>> - (setq rmail-output-reset-deleted-flag t
>>   	rmail-delete-after-output t)
>> - undelete message N-1
>> - press 'o': no message is displayed and you see (deleted) message N
>
>I cannot reproduce this.  Is this in "emacs -Q"?  If so, could you
>please show a complete recipe, starting from "emacs -Q", and
>preferably excluding any parts that are not needed for showing the
>issue?

Yes, I used a clean environment.  Today or tomorrow I should be able to
be more detailed.

>Also, the Subject says "27.1"; if this problem exists in Emacs 27.1 as
>well, please tell, as that could change the priority of handling the
>issue, given that Emacs 27.2 is in the last stages of pretesting.

I am running emacs 27.1 but with the above 5 rmail libraries downloaded
from trunk, which include various bug corrections.

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

From: Francesco Potortì <pot <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Mon, 15 Feb 2021 12:26:09 +0100

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

Trying again.

This is Debian 27.1 with the following libraries taken from trunk as of
11 February (unchanged as of today):

 rmail
 rmailedit
 rmailmm
 rmailout
 rmailsum

And the attached files used for testing:

 /tmp/RMAILbug
 /tmp/bug.el

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.

[RMAILbug (application/octet-stream, attachment)]

[bug.el (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Mon, 15 Feb 2021 17:35:14 +0200

> From: Francesco Potortì <pot <at> gnu.org>
> Date: Mon, 15 Feb 2021 12:26:09 +0100
> Cc: 46463 <at> 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).         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^

Why it is a problem for you that Rmail goes to the very next message
in this situation?

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

From: Francesco Potortì <pot <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Mon, 15 Feb 2021 17:19:19 +0100

>> From: Francesco Potortì <pot <at> gnu.org>
>> Date: Mon, 15 Feb 2021 12:26:09 +0100
>> Cc: 46463 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Francesco Potortì <pot <at> gnu.org>
Cc: 46463 <at> debbugs.gnu.org
Subject: Re: bug#46463: 27.1; rmailout glitch
Date: Mon, 15 Feb 2021 19:10:24 +0200

> From: Francesco Potortì <pot <at> gnu.org>
> Date: Mon, 15 Feb 2021 17:19:19 +0100
> Cc: 46463 <at> debbugs.gnu.org
> 
> >  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:

But if you invoke 'o' with an argument N under
rmail-output-reset-deleted-flag non-nil, it outputs N messages,
regardless of whether they were deleted.  Since that option says to
reset the "deleted" flag before outputting, it makes sense to
disregard the "deleted" flag when moving as well.  This is the
reasoning behind the behavior you see.

> 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.

The command assumes that you may wish to output more deleted messages,
so it moves to the next message, whether deleted or not.

> 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).

It does more than that, as the documentation says.

> >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.

Then I guess this is another optional behavior, and it needs to be
coded.  The current code doesn't support that, and it is documented.
Would you like to submit a patch to that effect, perhaps including
addition of a 3rd value to rmail-output-reset-deleted-flag?

Thanks.

Previous Next

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