bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Amin Bandali]

This has been a pet peeve of mine for a while now, so I thought I'd send
in a report.

Currently, the `message-newline-and-reformat' function (bound to M-RET
in `message-mode') does not insert an empty space after the citation
prefix (e.g. '>') when reformatting the lines following the point in a
common use scenario.  I would like the behaviour to change, or at least
an option be added to have `message-newline-and-reformat' insert a space
after each '>'.

Example:

--8<---------------cut here---------------start------------->8---
> test0
>
> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12
--8<---------------cut here---------------end--------------->8---

If you put the point on the line between test0 and test1, after the '>'
character, and press M-RET, it will result in:

--8<---------------cut here---------------start------------->8---
> test0
>



>
> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11
>test12
--8<---------------cut here---------------end--------------->8---

Notice the absence of space between ">" and "test12".  If the original
line is long enough for the filled version to span several lines, all of
them will not have a space after '>', similar to the above example.

Instead, I would like pressing M-RET in the above example to yield:

--8<---------------cut here---------------start------------->8---
> test0
>



>
> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11
> test12
--8<---------------cut here---------------end--------------->8---

As somewhat of a workaround, one could manually insert a space on the
line between "test0" and "test1" before calling the function, but that
results in the two middle lines (which only consist of '>') to have an
extraneous trailing space, i.e. "> ".

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Lars Ingebrigtsen]

Amin Bandali <bandali@gnu.org> writes:

> Currently, the `message-newline-and-reformat' function (bound to M-RET
> in `message-mode') does not insert an empty space after the citation
> prefix (e.g. '>') when reformatting the lines following the point in a
> common use scenario.  I would like the behaviour to change, or at least
> an option be added to have `message-newline-and-reformat' insert a space
> after each '>'.
>
> Example:
>
>> test0
>>
>> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12

The problem here is that there's no space after that > character.  If it
had been

> test0
> 
> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12

instead (if that trailing space survives the mailing process) then you get

> test0
> 



> 
> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11
> test12

Hm...  OK, I think I found it -- I think there was a reversed check for
the length of the spaces in the following paragraph?  I pushed a fix to
Emacs 28 that seems to fix this use case, but I'm not exactly confident
that this doesn't introduce other oddities.

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

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Amin Bandali]

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

Lars Ingebrigtsen writes:

> Amin Bandali <bandali@gnu.org> writes:
>
>> Currently, the `message-newline-and-reformat' function (bound to M-RET
>> in `message-mode') does not insert an empty space after the citation
>> prefix (e.g. '>') when reformatting the lines following the point in a
>> common use scenario.  I would like the behaviour to change, or at least
>> an option be added to have `message-newline-and-reformat' insert a space
>> after each '>'.
>>
>> Example:
>>
>>> test0
>>>
>>> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12
>
> The problem here is that there's no space after that > character.  If it
> had been
>
>> test0
>> 
>> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12
>
> instead (if that trailing space survives the mailing process) then you get
>
>> test0
>> 
>
>
>
>> 
>> test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11
>> test12
>

Right, but I don't think there is normally a space there otherwise
either.  For instance, when replying with (quoting) the original in
Gnus, Gnus and/or Message don't insert a trailing space after the '>'
when there is no character on that line.

> 
> Hm...  OK, I think I found it -- I think there was a reversed check
> for the length of the spaces in the following paragraph?  I pushed a
> fix to Emacs 28 that seems to fix this use case, but I'm not exactly
> confident that this doesn't introduce other oddities.

Thanks, it does seem to cover this case.  But now, there's a trailing
single space after the first '>' with no other characters after it.
Would it make sense to remove that once the filling/reformatting of the
paragraph is done?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Lars Ingebrigtsen]

Amin Bandali <bandali@gnu.org> writes:

> Thanks, it does seem to cover this case.  But now, there's a trailing
> single space after the first '>' with no other characters after it.
> Would it make sense to remove that once the filling/reformatting of the
> paragraph is done?

Hm...  I guess that's possibly (but sounds a bit finicky), but I'm not
sure that's necessarily more correct than the old behaviour.

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

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Amin Bandali]

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

Lars Ingebrigtsen writes:

> Amin Bandali <bandali@gnu.org> writes:
>
>> Thanks, it does seem to cover this case.  But now, there's a trailing
>> single space after the first '>' with no other characters after it.
>> Would it make sense to remove that once the filling/reformatting of the
>> paragraph is done?
>
> Hm...  I guess that's possibly (but sounds a bit finicky), but I'm not
> sure that's necessarily more correct than the old behaviour.

I think it would be more consistent, if not necessarily more correct, to
not insert that extraneous whitespace.

Also, I've noticed another side effect of this change: now even short
lines after point get filled, which is rather annoying.  For instance,
if you put the cursor after the first '>' and hit M-RET

--8<---------------cut here---------------start------------->8---
>
> Regards,
> X
> Y
--8<---------------cut here---------------end--------------->8---

you get:

--8<---------------cut here---------------start------------->8---
>



> 
> Regards, X Y
--8<---------------cut here---------------end--------------->8---

IMO filling should only be done when the line length exceeds the line
length limit, like it did before this change.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix

[Lars Ingebrigtsen]

Amin Bandali <bandali@gnu.org> writes:

> Also, I've noticed another side effect of this change: now even short
> lines after point get filled, which is rather annoying.  For instance,
> if you put the cursor after the first '>' and hit M-RET
>
>>
>> Regards,
>> X
>> Y
>
> you get:
>
>>
>
>> 
>> Regards, X Y
>
> IMO filling should only be done when the line length exceeds the line
> length limit, like it did before this change.

That's just because you hit `M-RET' on the ">" line.  If you hit it
anywhere else, all the lines are filled.

So it's just more consistent.

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