GNU bug report logs - #9841
23.3; rmail-edit-current-message adds extra '>'s to Froms...

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9841 in the body.
You can then email your comments to 9841 AT debbugs.gnu.org in the normal way.

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

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

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.3; rmail-edit-current-message adds extra '>'s to Froms...
Date: Sat, 22 Oct 2011 12:05:57 -0700

Start with a Rmail message (this one will do) not containing MIME that
contains lines like the following:

>From level 1
>>From level 2
>>>From level 3

Hit 'e' to edit the message.  Notice that nothing changes.  Now hit ^c^c
or ^c^] to stop editing (the later is supposed to abort, leaving the
message unchanged).  Notice that your message now has one more > in
front of each of the from lines:

>>From level 1
>>>From level 2
>>>>From level 3

You can repeat this as many times as you like, adding more and more >'s.


Towards a patch, I notice that rmail-cease-edit has the following code:

rmailedit.el:135:
  ;; Disguise any "From " lines so they don't start a new message.
  (goto-char (point-min))
  (or rmail-old-pruned (forward-line 1))
  (while (re-search-forward "^>*From " nil t)
    (beginning-of-line)
    (insert ">")
    (forward-line))

There is no corresponding code in the rmail-edit-current-message or the
viewing code that I can find.


    This probably needs more thought, but I think the decode code should
remove one >, and the incorporate new messages and done editting code
should add one > (as above).  Note this is related to bug #6574: Rmail
23 uses a broken mailbox format (mboxo) instead of a sane one like
mboxrd.

    I note that fetchmail to mbox loses information because it only adds
a > to From's without one already.  This is arguably not Rmail's fault,
however.

- Mark

Message #10 received at 9841-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 9841-done <at> debbugs.gnu.org
Subject: Re: bug#9841: 23.3;
	rmail-edit-current-message adds extra '>'s to Froms...
Date: Fri, 07 Dec 2012 04:03:58 -0500

Version: 24.4

Mark Lillibridge wrote:

> Start with a Rmail message (this one will do) not containing MIME that
> contains lines like the following:

Actually, I can only reproduce this with a message that _is_ MIME, ie
has a "MIME-version: 1.0" header (which almost everything does).
For non-MIME messages, rmail-show-message-1 _does_ add >, which is
why rmail-cease-edit tries to put them back. Anyway, I installed a
change to make it not do that for MIME messages, which have not been
unescaped during display.

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

From: Mark Lillibridge <mdl <at> alum.mit.edu>
To: <9841 <at> debbugs.gnu.org>, rgm <at> gnu.org
Subject: Re: bug#9841: closed (Re: bug#9841: 23.3; rmail-edit-current-message
	adds extra '>'s to Froms...)
Date: Tue, 01 Jan 2013 13:53:52 -0800

Glenn Morris <rgm <at> gnu.org> wrote:
> Mark Lillibridge wrote:
> 
> > Start with a Rmail message (this one will do) not containing MIME that
> > contains lines like the following:
> 
> Actually, I can only reproduce this with a message that _is_ MIME, ie
> has a "MIME-version: 1.0" header (which almost everything does).
> For non-MIME messages, rmail-show-message-1 _does_ add >, which is
> why rmail-cease-edit tries to put them back. Anyway, I installed a
> change to make it not do that for MIME messages, which have not been
> unescaped during display.

    You're right; this problem does not occur with non-MIME messages
under 24.2 (my current test system).

    I think your patch may not work correctly if the user adds a "From "
line to a MIME message.  Seems like there are two choices: (1) give an
error in that case and refuse to exit editing (similar to the screwed up
headers case) or (2) unescape From lines when the edit starts and
re-escape them when the edit finishes.  (2) seems friendlier to users as
it means users don't have to manually escape From lines when editing.

- Mark

Previous Next

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