bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Mark Lillibridge]

    This is easy to reproduce; just send yourself a plain text message
that has no extra blank lines after it.  Incorporate it into Rmail and
notice that it is displayed with an extra blank line.  For example,

> Date: Sat, 19 Nov 2011 12:05:50 -0800
> Subject: no blank lines follow
> From: Mark Lillibridge <lillibridge@gmail.com>
> To: mdl@alum.mit.edu
> 
> this is the only line
> 

where I have added "> " before each line of the displayed message.  If
you check the underlying mbox file, you'll see that indeed, "this is the
only line" is the last line of that message.  (Remember that messages in
mbox format start with a "From " line and are followed by a blank
separator line that does not count as part of the message.)  This extra
blank line is not displayed for MIME messages

    The fix should be pretty easy; just make sure to check that any
other code that might be relying on the contents of the decoded buffer
(output as seen, edit?) doesn't get broken.

- Mark

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Lars Ingebrigtsen]

Mark Lillibridge <mark.lillibridge@hp.com> writes:

>     This is easy to reproduce; just send yourself a plain text message
> that has no extra blank lines after it.  Incorporate it into Rmail and
> notice that it is displayed with an extra blank line.  For example,
>
>> Date: Sat, 19 Nov 2011 12:05:50 -0800
>> Subject: no blank lines follow
>> From: Mark Lillibridge <lillibridge@gmail.com>
>> To: mdl@alum.mit.edu
>> 
>> this is the only line
>> 
>
> where I have added "> " before each line of the displayed message.  If
> you check the underlying mbox file, you'll see that indeed, "this is the
> only line" is the last line of that message. 

(I'm going through old bug reports that unfortunately got no response at
the time.)

I'm unable to reproduce this in Emacs 28, but I'm not quite sure I'm
testing it correctly.  Are you still seeing this issue in recent Emacs
versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm unable to reproduce this in Emacs 28, but I'm not quite sure I'm
> testing it correctly.  Are you still seeing this issue in recent Emacs
> versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Mark Lillibridge]

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


Lars wrote:
>  I'm unable to reproduce this in Emacs 28, but I'm not quite sure I'm
>  testing it correctly.  Are you still seeing this issue in recent Emacs
>  versions?

    Yes, I can reproduce this in version 28.1.

    I'm attaching a *mbox* file (this is the format used by rmail),
lightly edited from one of my older rmail files to hide email addresses.
It has two messages, the first with zero blank lines at the end and last
with 2 blank lines at the end.  If you find file it then do M-x
rmail-mode and look at the first message, you will see that it has an
extra blank line at the end when displayed.  The last one doesn't.  (go
to the end of message with esc > or turn on line numbering to see where
the displayed message ends.)

    If you look at the rmail file before doing rmail-mode, you can see
the underlying formatting.  You will see a blank line between the first
and second message; this is part of the mbox formatting, not a part of
either message.

from https://en.wikipedia.org/wiki/Mbox
    The mbox format uses a single blank line followed by the string 'From '
    (with a space) to delimit messages; this can create ambiguities if a
    message contains the same sequence in the message text.

(The original reproduction instructions probably no longer work because
it's actually quite hard to send a message that's not using MIME these
days.)

    To add insult to injury, if you attempt to forward the message, Rmail
will include the spurious blank line in the message it forwards.  I hit
'f' for this in emacs28.1 -q and get a # part with the blank line before
the closing tag.

- Mark
PS, I have gzipped the mbox file to prevent intermediate mailers from
corrupting it.

[-- Attachment #2: sample_mbox.gz --]
[-- Type: application/gzip, Size: 1039 bytes --]

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Eli Zaretskii]

> From: Mark Lillibridge <mdl@alum.mit.edu>
> Date: Sun, 25 Sep 2022 09:36:27 -0700
> 
>     I'm attaching a *mbox* file (this is the format used by rmail),
> lightly edited from one of my older rmail files to hide email addresses.
> It has two messages, the first with zero blank lines at the end and last
> with 2 blank lines at the end.  If you find file it then do M-x
> rmail-mode and look at the first message, you will see that it has an
> extra blank line at the end when displayed.  The last one doesn't.  (go
> to the end of message with esc > or turn on line numbering to see where
> the displayed message ends.)
> 
>     If you look at the rmail file before doing rmail-mode, you can see
> the underlying formatting.  You will see a blank line between the first
> and second message; this is part of the mbox formatting, not a part of
> either message.
> 
> from https://en.wikipedia.org/wiki/Mbox
>     The mbox format uses a single blank line followed by the string 'From '
>     (with a space) to delimit messages; this can create ambiguities if a
>     message contains the same sequence in the message text.
> 
> (The original reproduction instructions probably no longer work because
> it's actually quite hard to send a message that's not using MIME these
> days.)
> 
>     To add insult to injury, if you attempt to forward the message, Rmail
> will include the spurious blank line in the message it forwards.  I hit
> 'f' for this in emacs28.1 -q and get a # part with the blank line before
> the closing tag.

Can you explain why this is a problem?  That is, why does it matter
that a message, as shown in the Rmail reading buffer, has extra empty
lines at the end?  I use Rmail all the time, and know about these
extra empty lines, but they never bother me, because I don't need to
read empty lines.  And forwarding a message with an extra empty line
also should not cause any trouble on the receiving end.

So I'm not sure we should do anything with this bug.

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you explain why this is a problem?  That is, why does it matter
> that a message, as shown in the Rmail reading buffer, has extra empty
> lines at the end?  I use Rmail all the time, and know about these
> extra empty lines, but they never bother me, because I don't need to
> read empty lines.  And forwarding a message with an extra empty line
> also should not cause any trouble on the receiving end.

It doesn't sound optimal.

bug#10080: 23.3; Rmail shows an extra blank line at the end when displaying a non-MIME message

[Mark Lillibridge]

Eli Zaretskii <eliz@gnu.org> writes:

>  Can you explain why this is a problem?  That is, why does it matter
>  that a message, as shown in the Rmail reading buffer, has extra empty
>  lines at the end?  I use Rmail all the time, and know about these
>  extra empty lines, but they never bother me, because I don't need to
>  read empty lines.  And forwarding a message with an extra empty line
>  also should not cause any trouble on the receiving end.
>  
>  So I'm not sure we should do anything with this bug.

    I agree this is not a particularly urgent/important bug.  If there
are more important bugs to fix and we have limited fixer bandwidth, I
don't think it would be unreasonable to mark this as "won't fix" or the
like.  I reopened this mostly because it was closed with the state
"fixed/gone", which is incorrect.

- Mark