bug#2941: rmail's new handling of Babyl files is odd

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Severity: serious

The new way in which Rmail treats Babyl files is odd:


emacs -Q
C-u M-x rmail RET some-babyl-file RET

"Replacing BABYL format with mbox format...done"

Before I can read the above message, it is replaced with the next:

"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"


Now I try to modify the buffer:

1) By adding a label.
a foo RET
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"

2) By editing a message.
e
make change to message
C-c C-c
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"

3) By deleting a message.
d
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"


Why do all of these leave the buffer unmodified? If Emacs crashes now,
I will lose information.


4) By expunging a message.
x
y

Finally, the buffer is marked modified.

Now if I press "s" to save the buffer, it is saved without warning,
clobbering the existing Babyl file. I was expecting a confirmation
prompt.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    Now if I press "s" to save the buffer, it is saved without warning,
    clobbering the existing Babyl file. I was expecting a confirmation
    prompt.

There is no way to ask for confirmation when saving a file.  (Look at
basic-save-buffer.)  Therefore I made it ask for confirmation when you
make a "major" change, that would imply changing formats later if you save the results.

Each kind of change can be treated as major or minor.

Editing the message should be major; I overlooked that one.
Please try the patch below.

I decided to treat changes in labels as minor, because showing a
message clears the "unseen" attribute.  Treating that as major implies
querying hen it shows an unseen message, which is typically just after
visiting the file.

It would be possible to treat changes in "unseen" as minor
and changes in "deleted" as major, etc.


*** rmailedit.el.~1.57.~	2009-03-14 14:26:33.000000000 -0400
--- rmailedit.el	2009-04-10 06:35:10.000000000 -0400
***************
*** 117,122 ****
--- 117,123 ----
  (defun rmail-cease-edit ()
    "Finish editing message; switch back to Rmail proper."
    (interactive)
+   (rmail-change-format)
    (if (rmail-summary-exists)
        (with-current-buffer rmail-summary-buffer
  	(rmail-summary-enable)))

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Richard M Stallman wrote:

> There is no way to ask for confirmation when saving a file.

write-file-functions?

It seems wrong to me that now I can end up converting a Babyl file to
mbox with no prompting at all.

> Editing the message should be major; I overlooked that one.
> Please try the patch below.

It prompts me when I abort an edit, which is inappropriate.
Aborting an edit does not modify the file.

If I answer "no" to the prompt, I'm stuck in the edit buffer, with no
way to get back to the regular Rmail buffer. One can just kill the
buffer and start again, but that is not obvious.

> I decided to treat changes in labels as minor, because showing a
> message clears the "unseen" attribute.  Treating that as major implies
> querying hen it shows an unseen message, which is typically just after
> visiting the file.
>
> It would be possible to treat changes in "unseen" as minor
> and changes in "deleted" as major, etc.

You could easily distinguish user-defined labels from attributes.
Or perhaps you should only treat "unseen" as minor.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    > There is no way to ask for confirmation when saving a file.

    write-file-functions?

I have doubts that it gives the right behavior
in the case of more than one hook function, etc.

    It seems wrong to me that now I can end up converting a Babyl file to
    mbox with no prompting at all.

Not so.  Any change that causes the buffer to be saved
will also prompt you (unless there's a bug and I overlooked some command).

    > It would be possible to treat changes in "unseen" as minor
    > and changes in "deleted" as major, etc.

    You could easily distinguish user-defined labels from attributes.

Would not help -- deleted and unseen are both attributes.

    Or perhaps you should only treat "unseen" as minor.

Maybe that would be better.  Would you like to try out that behavior?

    It prompts me when I abort an edit, which is inappropriate.
    Aborting an edit does not modify the file.

That is a bug; aborting the edit should not prompt.
Does this fix it?

*** rmailedit.el.~1.58.~	2009-04-10 10:16:48.000000000 -0400
--- rmailedit.el	2009-04-11 07:02:51.000000000 -0400
***************
*** 117,123 ****
  (defun rmail-cease-edit ()
    "Finish editing message; switch back to Rmail proper."
    (interactive)
!   (rmail-modify-format)
    (if (rmail-summary-exists)
        (with-current-buffer rmail-summary-buffer
  	(rmail-summary-enable)))
--- 117,124 ----
  (defun rmail-cease-edit ()
    "Finish editing message; switch back to Rmail proper."
    (interactive)
!   (if (buffer-modified-p)
!       (rmail-modify-format))
    (if (rmail-summary-exists)
        (with-current-buffer rmail-summary-buffer
  	(rmail-summary-enable)))
***************
*** 254,259 ****
--- 255,261 ----
    (widen)
    (delete-region (point-min) (point-max))
    (insert rmail-old-text)
+   (set-buffer-modified-p nil)
    (rmail-cease-edit)
    (rmail-highlight-headers))
  \f

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Richard M Stallman wrote:

>     It seems wrong to me that now I can end up converting a Babyl file to
>     mbox with no prompting at all.
>
> Not so.  Any change that causes the buffer to be saved
> will also prompt you (unless there's a bug and I overlooked some command).

There's the one that prompted this report:

emacs -Q
C-u M-x rmail RET foo RET  ; foo is a Babyl file with > 1 message
d
s
y

Now you have an mbox file, no prompting.

>     Or perhaps you should only treat "unseen" as minor.
>
> Maybe that would be better.  Would you like to try out that behavior?

If you're asking if I want to write a patch, then sorry, no.

> That is a bug; aborting the edit should not prompt.
> Does this fix it?

Aborting no longer prompts, but it marks the message as edited, which
is incorrect.

Also, aborting an edit now always marks the Rmail buffer as unmodified
(even if the initial Rmail file was mbox). It should restore the
pre-edit modification status.

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Glenn Morris wrote:

> Aborting no longer prompts, but it marks the message as edited, which
> is incorrect.
>
> Also, aborting an edit now always marks the Rmail buffer as unmodified
> (even if the initial Rmail file was mbox). It should restore the
> pre-edit modification status.

Also, I think the behaviour is confusing if someone starts from a
Babyl file, edits a message, and then ends the edit. They get prompted
about the mbox conversion at this point. What are they supposed to do
if they answer "no"? At this point, their Rmail buffer has
(apparently) disappeared and been replaced by the edit buffer, and
it's not obvious how to get out of the edit and back to the normal
Rmail buffer without saying "yes".

For all these reasons, I suggest it would be better to prompt
immediately after the "e" key is pressed, before the edit buffer is
created.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    For all these reasons, I suggest it would be better to prompt
    immediately after the "e" key is pressed, before the edit buffer is
    created.

I agree, and I will make that change.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    emacs -Q
    C-u M-x rmail RET foo RET  ; foo is a Babyl file with > 1 message
    d
    s
    y

Does this patch give good results?

*** rmail.el.~1.534.~	2009-04-10 10:13:07.000000000 -0400
--- rmail.el	2009-04-14 16:15:38.000000000 -0400
***************
*** 1458,1463 ****
--- 1458,1464 ----
    "Expunge and save RMAIL file."
    (interactive)
    (set-buffer rmail-buffer)
+   (rmail-modify-format)
    (rmail-expunge)
    ;; No need to swap buffers: rmail-write-region-annotate takes care of it.
    ;; (rmail-swap-buffers-maybe)

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    It fixes the above sequence; however I can still go from Babyl to mbox
    with no prompting by doing:

    C-u M-x rmail RET foo RET
    d
    x
    y

I think that y is the answer to a prompt.

It is a feature that rmail-expunge-confirm avoids prompting twice.
If it prompts you about whether to expunge at all, it doesn't
prompt a second time about the change in format.

Of course, this can be changed if people prefer.

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Richard M Stallman wrote:

>     It fixes the above sequence; however I can still go from Babyl to mbox
>     with no prompting by doing:
>
>     C-u M-x rmail RET foo RET
>     d
>     x
>     y
      C-x C-s
>
> I think that y is the answer to a prompt.

OK, yes, it is the "expunge deleted mail" prompt.

> It is a feature that rmail-expunge-confirm avoids prompting twice.

Really? At the very least, you have inconsistencies:

C-u M-x rmail RET foo RET
d
s

and

C-u M-x rmail RET foo RET
d
x
y
s             ; rather than C-x C-s

both prompt twice: separately about converting to mbox, then about
expunging messages. This seems entirely sensible to me.

> If it prompts you about whether to expunge at all, it doesn't
> prompt a second time about the change in format.

The "expunge deleted mail" prompt is something an Rmail user will have
seen many times, and will answer without expecting that in this one
particular instance there is a hidden second question about changing
the format of the Rmail file.

> Of course, this can be changed if people prefer.

The current behaviour doesn't make sense to me. (Probably the
rmail-modify-format call should just be in rmail-expunge rather than
in rmail-expunge-and-save.)

I should imagine that people who use Rmail, use it often. So anyone
using CVS will have already switched to mbox and will never encounter
this. People who wait for 23.1 will encounter it once only. Changing
it in 23.2 will be largely pointless.

bug#2941: rmail's new handling of Babyl files is odd

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 16 Apr 2009 13:31:40 -0400
> Cc: 2941@emacsbugs.donarmstrong.com
> 
> I should imagine that people who use Rmail, use it often. So anyone
> using CVS will have already switched to mbox and will never encounter
> this.

Not necessarily.  I, for example, have lots of mail archives from past
years, all in Babyl format (they are files produced by the `o'
command).  I don't intend to convert all of them to mbox, but I might
want to run Rmail on them occasionally.

Not sure what that means for what you are trying to argue.

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Eli Zaretskii wrote:

> Not necessarily.  I, for example, have lots of mail archives from past
> years, all in Babyl format (they are files produced by the `o'
> command).  I don't intend to convert all of them to mbox, but I might
> want to run Rmail on them occasionally.
>
> Not sure what that means for what you are trying to argue.

Ignore the last paragraph of my previous mail.
I was merely trying to say that I think it is important to get this right
_before_ 23.1.

The specifics are in the preceding paragraphs.

bug#2941: rmail's new handling of Babyl files is odd

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 2941@emacsbugs.donarmstrong.com,  rms@gnu.org
> Date: Thu, 16 Apr 2009 16:31:36 -0400
> 
> I was merely trying to say that I think it is important to get this right
> _before_ 23.1.

To that I wholeheartedly agree.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    C-u M-x rmail RET foo RET
    d
    x
    y
    s             ; rather than C-x C-s

    both prompt twice: separately about converting to mbox, then about
    expunging messages. This seems entirely sensible to me.

Remember that s also does expunge.  If you give two commands that can
query, you may get two quieries.

This says nothing about whether one command should query the user twice.
I find your argument unpersuasive.

If people generally want x to query twice, I won't argue against it,
but your pushing hard doesn't constitute people generally.

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Richard M Stallman wrote:

> Remember that s also does expunge.  If you give two commands that can
> query, you may get two quieries.
>
> This says nothing about whether one command should query the user twice.
> I find your argument unpersuasive.

I reiterate:

C-u M-x rmail RET foo RET
d
s

is one command that prompts twice (with the patch you proposed).

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    C-u M-x rmail RET foo RET
    d
    s

    is one command that prompts twice (with the patch you proposed).

Yes, prompting twice is the specific purpose of that patch.

So far, you are the only person who wants a command to prompt twice.
If people would generally like that, I won't object.  However, you
alone don't constitute "people in general".  Let's see what others
think, if they care.

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Richard M Stallman wrote:

>     C-u M-x rmail RET foo RET
>     d
>     s
>
>     is one command that prompts twice (with the patch you proposed).
>
> Yes, prompting twice is the specific purpose of that patch.

Let's forget about this "prompt twice" issue.

My point is, Rmail should not convert a Babyl file to mbox format
without specifically asking the question "Convert this file to mbox
format?" (or whatever phrasing you like).

I have provided simple examples where this does not happen.

I do not accept that the "expunge deleted messages?" prompt is an
acceptable substitute.

I don't really care whether you ask one or two questions, but you
should be consistent. If you're against two questions, I imagine you
will have to modify the prompts, eg "Expunge deleted messages, and
convert this file to mbox?".

And that's all I have to say on this.

bug#2941: rmail's new handling of Babyl files is odd

[Stefan Monnier]

> My point is, Rmail should not convert a Babyl file to mbox format
> without specifically asking the question "Convert this file to mbox
> format?" (or whatever phrasing you like).

Indeed, that was also my point.


        Stefan

bug#2941: rmail's new handling of Babyl files is odd

[Stefan Monnier]

>     It fixes the above sequence; however I can still go from Babyl to mbox
>     with no prompting by doing:

>     C-u M-x rmail RET foo RET
>     d
>     x
>     y

> I think that y is the answer to a prompt.

> It is a feature that rmail-expunge-confirm avoids prompting twice.

I think it's generally good to avoid prompting multiple times.  But it's
also important to make sure that the user gets prompted separately for
"conversion to mbox format".


        Stefan

bug#2941: marked as done (rmail's new handling of Babyl files is odd)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]


Your message dated Mon, 18 May 2009 12:58:52 -0400
with message-id <87ws8epctv.fsf@cyd.mit.edu>
and subject line Re: bug#2941: rmail's new handling of Babyl files is odd
has caused the Emacs bug report #2941,
regarding rmail's new handling of Babyl files is odd
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2941: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2941
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3121 bytes --]

From: Glenn Morris <rgm@gnu.org>
To: bug-gnu-emacs@gnu.org
Subject: rmail's new handling of Babyl files is odd
Date: Thu, 09 Apr 2009 15:48:12 -0400
Message-ID: <xd63hdwqv7.fsf@fencepost.gnu.org>

Severity: serious

The new way in which Rmail treats Babyl files is odd:


emacs -Q
C-u M-x rmail RET some-babyl-file RET

"Replacing BABYL format with mbox format...done"

Before I can read the above message, it is replaced with the next:

"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"


Now I try to modify the buffer:

1) By adding a label.
a foo RET
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"

2) By editing a message.
e
make change to message
C-c C-c
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"

3) By deleting a message.
d
"Marking buffer unmodified to avoid rewriting Babyl file as mbox file"


Why do all of these leave the buffer unmodified? If Emacs crashes now,
I will lose information.


4) By expunging a message.
x
y

Finally, the buffer is marked modified.

Now if I press "s" to save the buffer, it is saved without warning,
clobbering the existing Babyl file. I was expecting a confirmation
prompt.




[-- Attachment #3: Type: message/rfc822, Size: 1426 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: rms@gnu.org
Cc: 2941-done@emacsbugs.donarmstrong.com
Subject: Re: bug#2941: rmail's new handling of Babyl files is odd
Date: Mon, 18 May 2009 12:58:52 -0400
Message-ID: <87ws8epctv.fsf@cyd.mit.edu>

> >> C-u M-x rmail RET foo RET
> >> d
> >> x
> >> y
> >> C-x C-s
> >
> > Could you propose a patch that catches this case?
>
> I can easily make this do whatever people generally want.
> I did not want to change it for one vociferous person,
> but I will gladly change to follow the general preference.

OK, I see you've done that.  Thanks.

bug#2941: rmail's new handling of Babyl files is odd

[Chong Yidong]

> It fixes the above sequence; however I can still go from Babyl to mbox
> with no prompting by doing:
>
> C-u M-x rmail RET foo RET
> d
> x
> y
> C-x C-s

Could you propose a patch that catches this case?

bug#2941: rmail's new handling of Babyl files is odd

[Glenn Morris]

Chong Yidong wrote:

>> C-u M-x rmail RET foo RET
>> d
>> x
>> y
>> C-x C-s
>
> Could you propose a patch that catches this case?

Sorry, no.

bug#2941: rmail's new handling of Babyl files is odd

[Richard M Stallman]

    >> C-u M-x rmail RET foo RET
    >> d
    >> x
    >> y
    >> C-x C-s
    >
    > Could you propose a patch that catches this case?

I can easily make this do whatever people generally want.
I did not want to change it for one vociferous person,
but I will gladly change to follow the general preference.

bug#2941: rmail's new handling of Babyl files is odd

[Chong Yidong]

> >> C-u M-x rmail RET foo RET
> >> d
> >> x
> >> y
> >> C-x C-s
> >
> > Could you propose a patch that catches this case?
>
> I can easily make this do whatever people generally want.
> I did not want to change it for one vociferous person,
> but I will gladly change to follow the general preference.

Please make the change, then---either there should be a second prompt,
or the first prompt should be changed in this case to make it clear that
the file will be converted.

Thank you.