bug#46463: 27.1; rmailout glitch

[Eli Zaretskii <eliz@gnu.org>]

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