[mu4e bug] Spurious line breaks when quoting a message in a reply.

[jakecoble]

EDIT: This isn't a mu4e bug. Correction here

Describe the bug

When viewing a message, mu4e inserts newlines into the buffer to fit the message within the width of the window. When the user replies to that message, those newlines are copied into the compose buffer when the quote is created.

Consider an email with the following text.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam et imperdiet augue, in volutpat massa.

Morbi sed mattis metus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Vivamus consectetur enim non augue suscipit, vel sollicitudin lorem posuere.

Integer eget lacus massa. Donec fermentum condimentum tortor, in sodales mi. Suspendisse rutrum consectetur turpis a viverra. Proin cursus a massa at porttitor.

When the user replies to it, the following quote should be copied into the compose buffer, as it preserves the text and line breaks of the original message.

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam et imperdiet augue, in volutpat massa.
>
> Morbi sed mattis metus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Vivamus consectetur enim non augue suscipit, vel sollicitudin lorem posuere.
>
> Integer eget lacus massa. Donec fermentum condimentum tortor, in sodales mi. Suspendisse rutrum consectetur turpis a viverra. Proin cursus a massa at porttitor.

If the display is too small for the message, the message view buffer wraps the text like this.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam et
imperdiet augue, in volutpat massa.

Morbi sed mattis metus. Vestibulum ante ipsum primis in faucibus orci
luctus et ultrices posuere cubilia curae; Vivamus consectetur enim non
augue suscipit, vel sollicitudin lorem posuere.

Integer eget lacus massa. Donec fermentum condimentum tortor, in
sodales mi. Suspendisse rutrum consectetur turpis a viverra. Proin
cursus a massa at porttitor.

When the user then replies to the message, the following text is inserted into the compose buffer.

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam et
> imperdiet augue, in volutpat massa.
>
> Morbi sed mattis metus. Vestibulum ante ipsum primis in faucibus orci
> luctus et ultrices posuere cubilia curae; Vivamus consectetur enim non
> augue suscipit, vel sollicitudin lorem posuere.
>
> Integer eget lacus massa. Donec fermentum condimentum tortor, in
> sodales mi. Suspendisse rutrum consectetur turpis a viverra. Proin
> cursus a massa at porttitor.

Several newlines have been inserted. This is visible and ugly when the text is wrapped on smaller displays, such as mobile devices.

How to Reproduce

1. Compose an email to yourself that includes lines longer than 80 characters.
2. View the message, and reduce the size of the window until the text wraps.
3. Hit R to reply.

Environment

mu4e: 1.8.9 Emacs: 27.2 uname -r: 5.19.9-arch1-1

Checklist

• [x] you are running either the latest 1.6.x release, or a 1.8.x release (otherwise, please upgrade)
• [x] you are running mu4e without any third-party extensions (otherwise, make sure you can reproduce without those)
• [x] you have read all of the above

[jakecoble]

Correction: mu4e does not insert line breaks when displaying an email, gnus does. It's possible to disable this behavior with gnus-treat-fill-long-lines.

It's not clear to me whether mu4e should change its behavior when this option is enabled. Given that Emacs can already wrap lines, I think there's an argument to be made that gnus-treat-fill-long-lines is superfluous anyway.

[djcb]

Thanks for checking; are you saying mu4e is not respecting gnus-treat-fill-long-lines?

[jakecoble]

mu4e is doing nothing wrong in this case, as far as I can tell.

gnus-treat-fill-long-lines does what it's supposed to: insert hard newlines. mu4e dutifully copies the message when composing replies, and, since it doesn't know which newlines were added by gnus-treat-fill-long-lines and which weren't, it just copies them all.

I think this issue can be closed.