bug#39580: 26.2; missing newline in fcc when output file is in an rmail buffer

bug#39580: 26.2; missing newline in fcc when output file is in an rmail buffer

[Ken Olum]

The function gnus-output-to-rmail fails to ensure a blank line at the
end of the message being output in the case where the output file is an
mbox file viewed in an rmail buffer.  The needed code is in this
function, but triggers only when the output file is not in a buffer.
This causes messages in the output file to be merged together.

To reproduce:

emacs -Q
C-x m to compose message
edit outgoing message to add a line "Fcc: test-save" (for example) and
some body that does not have a blank line at the end.
C-c C-c to send message
Visit "test-save"
M-x rmail-mode
Select buffer "*sent mail to ...*"
C-c C-c to send message again

File "test-save" is now corrupt because it lacks a blank line at the
end.  To see that it is corrupt:

Send the same message yet again.
Select the "test-save" buffer.  It will look OK, but
Kill the "test-save" buffer.
Visit "test-save" again
M-x rmail-mode

Now the last two copies of the message will be concatenated into a
single message.

I propose fixing this by taking the code for inserting the blank line
that starts "(unless babyl  ; from gnus-output-to-mail" and moving it
before ";; Decide whether to append to a file or to an Emacs buffer." so
that it takes place for all mbox files.

There is a similar bug in gnus-output-to-mail that occurs when the file
is in a non-rmail buffer.  It makes the same mistake, but corrects it
next time by putting in another newline at the end of what it did
before.  However, it always adds the newline, so if the file is empty it
corrupts it by putting an extra blank line at the front.

                                        Ken

bug#39580: 26.2; missing newline in fcc when output file is in an rmail buffer

[Lars Ingebrigtsen]

Ken Olum <kdo@cosmos.phy.tufts.edu> writes:

> The function gnus-output-to-rmail fails to ensure a blank line at the
> end of the message being output in the case where the output file is an
> mbox file viewed in an rmail buffer.  The needed code is in this
> function, but triggers only when the output file is not in a buffer.
> This causes messages in the output file to be merged together.
>
> To reproduce:
>
> emacs -Q
> C-x m to compose message
> edit outgoing message to add a line "Fcc: test-save" (for example) and
> some body that does not have a blank line at the end.
> C-c C-c to send message
> Visit "test-save"
> M-x rmail-mode
> Select buffer "*sent mail to ...*"
> C-c C-c to send message again
>
> File "test-save" is now corrupt because it lacks a blank line at the
> end.

I'm able to reproduce this bug, but I'm not sure how
gnus-output-to-rmail is involved here?  As far as I can see, it's never
called by Message, and instead `message-output' is called to create the
file.

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

bug#39580: 26.2; missing newline in fcc when output file is in an rmail buffer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm able to reproduce this bug, but I'm not sure how
> gnus-output-to-rmail is involved here?  As far as I can see, it's never
> called by Message, and instead `message-output' is called to create the
> file.

Sorry; I see that message-output calls that function in some
circumstances...  but not by default; only if the file is on babyl
format?

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

bug#39580: 26.2; missing newline in fcc when output file is in an rmail buffer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I'm able to reproduce this bug, but I'm not sure how
>> gnus-output-to-rmail is involved here?  As far as I can see, it's never
>> called by Message, and instead `message-output' is called to create the
>> file.
>
> Sorry; I see that message-output calls that function in some
> circumstances...  but not by default; only if the file is on babyl
> format?

I was even more confused here -- your recipe included all the elements
necessary to reproduce all parts of the bug, but I just didn't read it
correctly.

I've now fixed this bug in Emacs 28.

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