bug#46463: 27.1; rmailout glitch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#46463: 27.1; rmailout glitch

Eli Zaretskii
> From: Francesco Potortì <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#46463: 27.1; rmailout glitch

Eli Zaretskii
> From: Francesco Potortì <[hidden email]>
> Date: Mon, 15 Feb 2021 12:26:09 +0100
> Cc: [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|

bug#46463: 27.1; rmailout glitch

Francesco Potortì-2
>> From: Francesco Potortì <[hidden email]>
>> Date: Mon, 15 Feb 2021 12:26:09 +0100
>> Cc: [hidden email]
>>
>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#46463: 27.1; rmailout glitch

Eli Zaretskii
> From: Francesco Potortì <[hidden email]>
> Date: Mon, 15 Feb 2021 17:19:19 +0100
> Cc: [hidden email]
>
> >  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.