* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
@ 2020-09-09 21:35 Amin Bandali
2020-09-10 21:28 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Amin Bandali @ 2020-09-09 21:35 UTC (permalink / raw)
To: 43299
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. "> ".
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
2020-09-09 21:35 bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix Amin Bandali
@ 2020-09-10 21:28 ` Lars Ingebrigtsen
2020-09-10 21:45 ` Amin Bandali
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-10 21:28 UTC (permalink / raw)
To: Amin Bandali; +Cc: 43299
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
2020-09-10 21:28 ` Lars Ingebrigtsen
@ 2020-09-10 21:45 ` Amin Bandali
2020-09-11 12:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Amin Bandali @ 2020-09-10 21:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 43299
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
2020-09-10 21:45 ` Amin Bandali
@ 2020-09-11 12:09 ` Lars Ingebrigtsen
2020-09-15 14:31 ` Amin Bandali
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-11 12:09 UTC (permalink / raw)
To: Amin Bandali; +Cc: 43299
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
2020-09-11 12:09 ` Lars Ingebrigtsen
@ 2020-09-15 14:31 ` Amin Bandali
2020-09-17 14:35 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Amin Bandali @ 2020-09-15 14:31 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 43299
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix
2020-09-15 14:31 ` Amin Bandali
@ 2020-09-17 14:35 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-17 14:35 UTC (permalink / raw)
To: Amin Bandali; +Cc: 43299
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-17 14:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-09 21:35 bug#43299: 28.0.50; message-newline-and-reformat does not insert space after citation prefix Amin Bandali
2020-09-10 21:28 ` Lars Ingebrigtsen
2020-09-10 21:45 ` Amin Bandali
2020-09-11 12:09 ` Lars Ingebrigtsen
2020-09-15 14:31 ` Amin Bandali
2020-09-17 14:35 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.