Change the expectation that emails should wrap at 80 characters

[Soren Stoutner]

The purpose of this email is to propose that the expectation that emails should be wrapped at 80 characters when they are sent should be dropped.

Currently, the code of conduct for the mailing lists says:

"Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l).”

https://www.debian.org/MailingLists/

I started thinking about this a few weeks ago when I received an email from a Debian Developer complaining that replies from my email client (KMail) looked odd because they truncated quoted lines in a way that did not lay out pleasingly. This was because I had set KMail to wrap lines at 80 characters.

The purpose of that email was to explain that KMail should be more intelligent in the way it wrapped the quoted lines, which is a fair point, although KMail handles things better than some of the emails I receive on the lists from time to time.

However, from a technical perspective, having the *sending* program decide where line breaks should be in an email doesn’t seem like the correct approach to me because, 1) the sending program does not know the screen width of the receiving program, and 2) there is large variability in the screen width of receiving devices, including cell phones who are often less than 80 characters wide.

I understand that there are historical reasons for the 80 character limit, but I believe that it is time to reassess best practices. My recommendation is that sending email programs should not wrap text at an arbitrary column, and that all wrapping of text should be handled by the receiving program, which is, of course, the only program that has insight into the width of the screen where the email is currently being displayed.

I have composed this email without an arbitrary column wrap, so that those receiving it can see how it is handled by their various clients and devices.

[Jeremy Stanley]

On 2025-02-26 11:21:42 -0700 (-0700), Soren Stoutner wrote:
[...]

Post by Soren Stoutner
I have composed this email without an arbitrary column wrap, so
that those receiving it can see how it is handled by their various
clients and devices.

I'll note that I'm somewhat of a traditionalist, reading list mail
(all E-mail really) with the current version of mutt from sid in an
emulated 80x24 character terminal, because I spent years in front of
serial terminals designed for that geometry (80x25 really but the
bottom row is occupied by the terminal's status bar) and got overly
accustomed to it.

Mutt's default configuration handles non-wrapped long lines fairly
gracefully, wrapping them at the last identifiable space character
before the terminal's margin, or at the last character if it's an
unbroken "word" longer than the terminal width, but then prefixing
subsequent wrapped lines with a "+" to indicate they were all
actually part of the same line originally. The only real hassle is
if I want to copy a very long URL out of a message, I either need to
piecemeal reassemble it from the lines that URL is spread across or
pipe the body into another tool that doesn't wrap anything. It's
likely there are config options for Mutt to alleviate this, I just
haven't bothered to go digging.

For the record, the editor I compose my messages in is set to wrap
at 68 columns in order to avoid my lines being too long when quoted
several indent levels deep, but I do sometimes manually re-flow any
quoted material I haven't trimmed from others' messages if I see
they're near to or exceeding my 80-character terminal margin.

[Marvin Renich]

Post by Jeremy Stanley
The only real hassle is
if I want to copy a very long URL out of a message, I either need to
piecemeal reassemble it from the lines that URL is spread across or
pipe the body into another tool that doesn't wrap anything. It's
likely there are config options for Mutt to alleviate this, I just
haven't bothered to go digging.

Try urlscan.

...Marvin

[Jeremy Stanley]

Post by Marvin Renich

Post by Jeremy Stanley
The only real hassle is
if I want to copy a very long URL out of a message, I either need to
piecemeal reassemble it from the lines that URL is spread across or
pipe the body into another tool that doesn't wrap anything. It's
likely there are config options for Mutt to alleviate this, I just
haven't bothered to go digging.

Try urlscan.

Thanks, yes that's what I mean by piping the body into another tool.
Both urlscan and the older urlview are probably fine if mutt is
running on your local system, in my case it's running on a remote
system and I just want to be able to copy the URLs from my terminal
without anything fancy trying to interpret or truncate/abbreviate
them, react to my pointer, et cetera.

Setting a macro to pipe the body through less or vi(ew) has been
working well enough for my needs, but some quick testing indicates
that if I override markers to no in my muttrc to get rid of the "+"
at the start of wrapped lines, that basically solves the long URL
copying problem, albeit at the expense of no longer knowing whether
mutt wrapped a line for me (not a huge loss, in my opinion).

[Vincent Lefevre]

Post by Jeremy Stanley
Mutt's default configuration handles non-wrapped long lines fairly
gracefully, wrapping them at the last identifiable space character
before the terminal's margin, or at the last character if it's an
unbroken "word" longer than the terminal width, but then prefixing
subsequent wrapped lines with a "+" to indicate they were all
actually part of the same line originally. The only real hassle is
if I want to copy a very long URL out of a message, I either need to
piecemeal reassemble it from the lines that URL is spread across or
pipe the body into another tool that doesn't wrap anything. It's
likely there are config options for Mutt to alleviate this, I just
haven't bothered to go digging.

Unset the $markers variable (but you will lose the "long line"
information also for the other lines, which might not be really
important; alternatively, you may define a key binding to toggle
the $markers setting).

[Andrea Pappacoda]

Hi Soren,

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that
emails should be wrapped at 80 characters when they are sent should be
dropped.

Most GUI clients handle long lines just fine. Some others, like the aerc
TUI client (which I use), don't (by default).

It is worth noting that some people in the past tried to solve this
wrapping issue with a proposed standard, [RFC 3676], which defines
"Format=Flowed" emails. Such messages requires client capable of
composing them, and many do, but some popular ones don't.

In format=flowed messages, lines are hard-wrapped "transparently". Long
lines are wrapped with line breaks, but with a trailing space. Receiving
clients then consider lines with a trailing space a single logical line,
and are free to re-wrap as they prefer. If you receiving client does not
support format=flowed, though, you'll just see a message wrapped at 72
cols.

Choosing between sending long lines and flowed text is, to me,
a trade-off. Format=flowed requires sender support, but looks good on
"dumb" clients. Long lines do not require any special sender support,
but looks odd "dumb" clients.

In any case, I feel discussing about RFC 3676 might be a bit off-topic
on -devel, so I'll end it here.

Post by Soren Stoutner
I started thinking about this a few weeks ago when I received an email
from a Debian Developer complaining that replies from my email client
(KMail) looked odd because they truncated quoted lines in a way that
did not lay out pleasingly. This was because I had set KMail to wrap
lines at 80 characters.

(sorry, I didn't mean to haunt your thoughts)

Bye!

[RFC 3676]: https://datatracker.ietf.org/doc/html/rfc3676

[Marco d'Itri]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that
emails should be wrapped at 80 characters when they are sent should be
dropped.

I am opposed.

[Bastian Blank]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that emails should be wrapped at 80 characters when they are sent should be dropped.

You MUA lacks support for RFC 2646, which is 25 years old.

Also it creates Message-Id without a proper FQDN.

Please just leave us alone.

Bastian

[Jeremy Sowden]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that
emails should be wrapped at 80 characters when they are sent should be
dropped.

No, thanks.

J.

[Andrej Shadura]

Hello,

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that emails should be wrapped at 80 characters when they are sent should be dropped.

Yes, please. Long due.

[Jonathan Dowland]

Can we strongly recommend format=flowed instead?

[Timo Röhling]

Post by Jonathan Dowland
Can we strongly recommend format=flowed instead?

+1

I've been using format=flowed for quite a while now, and it works
fine in general. The BTS website lacks rendering support for it,
which is the one place where flowed formatting would be useful for
me, but thanks to graceful degradation I'm not worse off than
without it.


Cheers
Timo

[Blair Noctis]

It's kinda funny how in this world in 2025, where and when all computers possess processing power several magnitudes higher than Apollo Guidance Computer, some still believe that text should be pre-formatted to a fixed length no matter what, because their devices and/or reading facilities are, just like AGC, made for and only for that fixed length, obviously unable to rearrange/re-format it, while others with devices which have smaller screen estate, yet re-format and render other, more complex content no problemo, or just like their readings put at a different display length, actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.

I also appreciate how some object without a reason a proposal, content aside, with at least their reasoning and considerations laid out.

[Vincent Lefevre]

Post by Blair Noctis
It's kinda funny how in this world in 2025, where and when all
computers possess processing power several magnitudes higher than
Apollo Guidance Computer, some still believe that text should be
pre-formatted to a fixed length no matter what, because their
devices and/or reading facilities are, just like AGC, made for and
only for that fixed length, obviously unable to rearrange/re-format
it, while others with devices which have smaller screen estate, yet
re-format and render other, more complex content no problemo, or
just like their readings put at a different display length, actually
struggle to read the hard-wrapped-at-80-then-wrapped-again text.

At least, 80-column text remains readable even on small screens,
contrary to most PDFs, which are also preformatted and are often
used nowadays (including as email contents), even when this is not
justified.

[Andrej Shadura]

Hello,

Post by Vincent Lefevre
At least, 80-column text remains readable even on small screens,
contrary to most PDFs, which are also preformatted and are often
used nowadays (including as email contents), even when this is not
justified.

That’s not entirely true: 80-column text often doesn’t fit on mobile phone screens, and because it’s pre-formatted, it cannot be reflowed easily, so it ends up an unreadable mess of alternating long and short lines (the short ones being the result of long ones being wrapped but not being long enough to actually fill the line).

I very much prefer long non-preformatted lines to be wrapped by the device itself to match the screen it has.

[The Wanderer]

Post by Andrej Shadura
Hello,

Post by Vincent Lefevre
At least, 80-column text remains readable even on small screens,
contrary to most PDFs, which are also preformatted and are often
used nowadays (including as email contents), even when this is not
justified.

That’s not entirely true: 80-column text often doesn’t fit on mobile
phone screens, and because it’s pre-formatted, it cannot be reflowed
easily, so it ends up an unreadable mess of alternating long and
short lines (the short ones being the result of long ones being
wrapped but not being long enough to actually fill the line).

That *is* a pain to read, agreed. I encounter it on non-mobile as well -
even with a much wider screen - in replies sent by people whose mail
software doesn't handle rewrapping paragraphs as a block, rather than
just cutting each "too-long" line into two, and who don't fix that by
hand before sending.

I still prefer that disadvantage over the disadvantage(s) of
unlimited-length lines.

Post by Andrej Shadura
I very much prefer long non-preformatted lines to be wrapped by the
device itself to match the screen it has.

In my case, my screen *is* very much larger, and the mail-reading window
(for a variety of reasons, some of which are probably just inertia, some
of which aren't and would be hard to change because they're on the
design level) is as well. That latter is for multiple reasons; the main
one is because I need the width for the list-of-messages pane, with its
variety of columns, and there's nothing else to be done with that width
for the message-body ("reading") pane, nor any other viable place in the
window to put that latter pane where it wouldn't need to take up that
same width.

But I still don't want long lines, and find them hard to read, at the
lengths that are presented by that combination of screen and window
widths.


I would be greatly displeased by a move to stop disfavoring lines longer
than about what the existing conventions call for; there are already far
too many cases where people send mail that disregards those
conventions, and that already adds to my cost to read such mails, to the
point that I treat seeing it as one of the weights on the side of the
scale for the decision to just ignore that mail as not worth my time to
read.

(I do recognize, however, that the flip side of that may also be true
for people who read in different environments and find the
hard-line-wrapped mails to be harder to read in those environments.)

[Jonathan Dowland]

Post by Andrej Shadura
That’s not entirely true: 80-column text often doesn’t fit on mobile
phone screens, and because it’s pre-formatted, it cannot be reflowed
easily, so it ends up an unreadable mess of alternating long and short
lines (the short ones being the result of long ones being wrapped but
not being long enough to actually fill the line).

*IFF* your reader supports format=flowed, you can have the best of both
worlds. Essentially you wrap at a column <80 for "legacy" reasons, but
end each line that is part of a continuous sentence/paragraph with ' '.
Clients supporting format=flowed then know which lines can be conjoined
and which cannot, and can wrap to the end-user's preference.

We could even survey what MUAs people care about and settle on a column
to wrap at for those in the set which don't support format=flowed.

[Aurélien COUDERC]

See below how your message ends up being wrapped in my mobile client.

That's readable for some strange/low value of $readable.

Agreed with Jonathan that if we can have senders and receivers understand fixed-but-flowing lines, then good for everyone.

But that's obviously not the case currently and if I need to choose my preference goes to line break is a line break vs. a 4000-word RFC explains when a line break is a line break.
At least, 80-column text remains readable
even on small screens,
contrary to most PDFs, which are also
preformatted and are often
used nowadays (including as email contents),
even when this is not
justified.

[Andrej Shadura]

Hello,

Post by Aurélien COUDERC
See below how your message ends up being wrapped in my mobile client.
That's readable for some strange/low value of $readable.
At least, 80-column text remains readable
even on small screens,
contrary to most PDFs, which are also
preformatted and are often
used nowadays (including as email contents),
even when this is not
justified.

This looks like Haiku :)

80 columns on small screens.
Strange value of readable.
Justified?

[t***@goirand.fr]

Post by Blair Noctis
actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.

The standard for email is 74 chars, not 80...


Thomas Goirand (zigo)

[Jonathan McDowell]

Post by t***@goirand.fr

Post by Blair Noctis
actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.

The standard for email is 74 chars, not 80...

RFC2822 says 78 characters.

https://datatracker.ietf.org/doc/html/rfc2822#section-2.1.1

J.

[Aurélien COUDERC]

Post by Jonathan McDowell

Post by t***@goirand.fr

Post by Blair Noctis
actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.

The standard for email is 74 chars, not 80...

RFC2822 says 78 characters.
https://datatracker.ietf.org/doc/html/rfc2822#section-2.1.1

What about 2 * pi * 12 so we close the loop ?

[Blair Noctis]

Post by t***@goirand.fr

Post by Blair Noctis
actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.

The standard for email is 74 chars, not 80...

It's a rant. The actual number didn't matter.

Post by t***@goirand.fr
You will see my text in *this* mail wrapped at column 72

Well.

I used to wrap my emails at 80, didn't seem to trigger rants about "breaking the standard". I don't think anyone actually checks the wrapping length with a ruler, but rather, that text is wrapped, and at "about the right length". (Do you really notice the difference between wrapping at 74/80?) So the status quo is we all have different ideas about wrapping and to wrap at what length, use different software that handle it differently and configure the software differently, but then aren't actually strict when it comes to actually reading the wrapped text.

To wrap or not to wrap, that's the problem. Or really, to wrap at (some fixed length) vs to wrap at (width of the window/control/view that contains the text, or if the software is capable enough, a customizable width).

It's also a preference, not a hard rule, so I see no end in this debate, just like spaces vs tabs, even though I believe that not to wrap, just like tabs, gives the receiving end more freedom.

FWIW, I've enabled format=flowed after learning it in this thread, hopefully also giving those who would rather wrap some freedom (as to let it reflow, which effectively means to wrap, or not).

--
Sdrager,
Blair Noctis

[Marc Haber]

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread, hopefully also giving those who would rather wrap some freedom (as to let it reflow, which effectively means to wrap, or not).

It's a bitch to reply to in mutt/vim.

Greetings
Marc

[Stephan Verbücheln]

Wrapping at 72 is intentional to allow a few levels of quotations. That
is where the slightly different numbers come from. The hard limit is 80
because of the 80x24 terminal convention.

Regards

[Andrea Pappacoda]

Hi Blair,

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread,
hopefully also giving those who would rather wrap some freedom (as to
let it reflow, which effectively means to wrap, or not).

Yeah, this email has been sent with the Format=Flowed Content-Type
parameter, but the message actually still has long, non-wrapped, lines
and you aren't using "soft breaks", (i.e., line breaks preceded by
a space, called "flowed lines" in the RFC). So... Setting format=flowed
doesn't bring any benefit in this case :/

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread, hopefully also giving those who would rather wrap some freedom (as to let it reflow, which effectively means to wrap, or not).
FWIW, I've enabled format=flowed after learning it in this thread,
hopefully also giving those who would rather wrap some freedom (as to
let it reflow, which effectively means to wrap, or not).

without "> ", of course :)
Note how lines are break at ~72 cols, but all end with a space apart
from the last one.

[Blair Noctis]

Post by Andrea Pappacoda
Hi Blair,

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread, hopefully
also giving those who would rather wrap some freedom (as to let it reflow,
which effectively means to wrap, or not).

Yeah, this email has been sent with the Format=Flowed Content-Type parameter,
but the message actually still has long, non-wrapped, lines and you aren't using
"soft breaks", (i.e., line breaks preceded by a space, called "flowed lines" in
the RFC). So... Setting format=flowed doesn't bring any benefit in this case :/

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread, hopefully
also giving those who would rather wrap some freedom (as to let it reflow,
which effectively means to wrap, or not).
FWIW, I've enabled format=flowed after learning it in this thread, hopefully
also giving those who would rather wrap some freedom (as to let it reflow,
which effectively means to wrap, or not).

without "> ", of course :)
Note how lines are break at ~72 cols, but all end with a space apart from the
last one.

Thanks Andrea,
for not only pointing it out but also analyzing the cause.
I guess it's a problem in Thunderbird which I currently use.
The comparison didn't work in it either;
only in the source view did I see the difference:
In your Content-Transfer-Encoding: quoted-printable reply message,
the original paragraph I sent has = at the end of each line,
while your correctly flowed message has =20.
I'm not sure how this happened,
but it's another reason I need to get off Thunderbird.

--
Sdrager,
Blair Noctis

[Tino Didriksen]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that emails
should be wrapped at 80 characters when they are sent should be dropped.

Wholeheartedly agree. Forced line wrapping is archaic, and not just in
emails. Any viewer or editor worth anything can display long lines in a way
that flows and indents with surroundings.

format=flowed would be neat, if it was widely implemented. It is not. And,
we shouldn't require specific software to use the mailing lists.

-- Tino Didriksen

[Holger Levsen]

Post by Tino Didriksen
Wholeheartedly agree. Forced line wrapping is archaic, and not just in
emails. Any viewer or editor worth anything can display long lines in a way
that flows and indents with surroundings.
format=flowed would be neat, if it was widely implemented. It is not. And,
we shouldn't require specific software to use the mailing lists.

your 2nd paragraph contradicts the 1st.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Die meisten Menschen können sich eher das Aussterben der Menschheit vorstellen
als das Ende von Herrschaftsideologie und Kapitalismus. (@elektra_42)

[Jonathan Dowland]

Post by Tino Didriksen
format=flowed would be neat, if it was widely implemented. It is not.
And, we shouldn't require specific software to use the mailing lists.

We could widen its implementation, at least with software we supply (and
things like the BTS or our own mailing list archives)

[Colin Watson]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that
emails should be wrapped at 80 characters when they are sent should be
dropped.

[...]

Post by Soren Stoutner
I understand that there are historical reasons for the 80 character
limit, but I believe that it is time to reassess best practices. My
recommendation is that sending email programs should not wrap text at
an arbitrary column, and that all wrapping of text should be handled by
the receiving program, which is, of course, the only program that has
insight into the width of the screen where the email is currently being
displayed.
I have composed this email without an arbitrary column wrap, so that
those receiving it can see how it is handled by their various clients
and devices.

I found your email difficult to read. I mostly read email in mutt in a
tmux shared with my IRC client, so I normally prefer to keep that window
fully maximized for the benefit of IRC, but email tends to be a bit hard
to read if it actually takes up the full width there. Sender-wrapped or
format=flowed (which mutt renders quite nicely by default these days)
works well for me as a receiver; unwrapped doesn't really.

This thread did, however, cause me to work out how to configure my
mailer to send format=flowed, since it does look as though that's
somewhat nicer for receivers who aren't using the same kind of dinosaur
setup as I am, and support seems to have improved since the last time I
looked at this eons ago. I needed this in ~/.config/nvim/init.vim
(should also work in ~/.vimrc):

au FileType mail setlocal formatoptions+=w

And this in ~/.muttrc:

set text_flowed

That seems to work pretty well. I reflowed the parts of your message
that I quoted here to match.

[Aaron Rainbolt]

Post by Colin Watson

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that
emails should be wrapped at 80 characters when they are sent should be
dropped.

[...]

Post by Soren Stoutner
I understand that there are historical reasons for the 80 character
limit, but I believe that it is time to reassess best practices. My
recommendation is that sending email programs should not wrap text at
an arbitrary column, and that all wrapping of text should be handled by
the receiving program, which is, of course, the only program that has
insight into the width of the screen where the email is currently being
displayed.
I have composed this email without an arbitrary column wrap, so that
those receiving it can see how it is handled by their various clients
and devices.

I found your email difficult to read. I mostly read email in mutt in a
tmux shared with my IRC client, so I normally prefer to keep that window
fully maximized for the benefit of IRC, but email tends to be a bit hard
to read if it actually takes up the full width there. Sender-wrapped or
format=flowed (which mutt renders quite nicely by default these days)
works well for me as a receiver; unwrapped doesn't really.

My two cents, for what it's worth: I had the exact same problem as you
when it came to difficulty reading unwrapped text... in the Gmail
webmail client. If something is hard to read both with your "dinosaur
setup" (as you call it) and my arguably hyper-modern setup, I think it's
probably a problem.

--
Aaron

Post by Colin Watson
This thread did, however, cause me to work out how to configure my
mailer to send format=flowed, since it does look as though that's
somewhat nicer for receivers who aren't using the same kind of dinosaur
setup as I am, and support seems to have improved since the last time I
looked at this eons ago. I needed this in ~/.config/nvim/init.vim
au FileType mail setlocal formatoptions+=w
set text_flowed
That seems to work pretty well. I reflowed the parts of your message
that I quoted here to match.
--

[Jeremy Stanley]

On 2025-02-27 13:29:59 +0000 (+0000), Colin Watson wrote:
[...]

Post by Colin Watson
I mostly read email in mutt in
a tmux shared with my IRC client, so I normally prefer to keep that
window fully maximized for the benefit of IRC, but email tends to be a
bit hard to read if it actually takes up the full width there.
Sender-wrapped or format=flowed (which mutt renders quite nicely by
default these days) works well for me as a receiver; unwrapped doesn't
really.
This thread did, however, cause me to work out how to configure my
mailer to send format=flowed, since it does look as though that's
somewhat nicer for receivers who aren't using the same kind of
dinosaur setup as I am, and support seems to have improved since the
last time I looked at this eons ago. I needed this in
au FileType mail setlocal formatoptions+=w
set text_flowed
That seems to work pretty well.

[...]

Thanks for the config details! Turns out we use basically the same
workflow (I run Mutt with vim as my message composer along several
other console-based client apps, including but not limited to IRC,
in persistent tmux session on a remote cloud VM), so this was
extremely helpful for me as well.

I'm composing and sending this with your suggestions applied, seems
to be working well so far. Thanks again!

[Jonathan Dowland]

Post by Colin Watson
set text_flowed
That seems to work pretty well. I reflowed the parts of your message
that I quoted here to match.

If you happen to use edit_headers, you *might* want something like this
(no idea if mutt has adopted it yet, ensures no trailing space on empty
header lines):

https://github.com/neomutt/neomutt/pull/1164

[Colin Watson]

Post by Jonathan Dowland

Post by Colin Watson
set text_flowed
That seems to work pretty well. I reflowed the parts of your
message that I quoted here to match.

If you happen to use edit_headers, you *might* want something like
this (no idea if mutt has adopted it yet, ensures no trailing space on
https://github.com/neomutt/neomutt/pull/1164

Doesn't affect me as I don't use formatoptions=a, but good to be
forewarned about, thanks!

[Aaron Schrab]

Post by Jonathan Dowland
If you happen to use edit_headers, you *might* want something like this
(no idea if mutt has adopted it yet, ensures no trailing space on empty
https://github.com/neomutt/neomutt/pull/1164

That PR shows as being merged several years ago. I'd supplied a similar
patch for the original mutt as well, but had that rejected. After that I
handled it in my vim by adding the following to
~/.vim/ftplugin/mail.vim:

setlocal formatoptions+=rawn2
autocmd CursorMoved,CursorMovedI <buffer> call autoformat#mail()

The function called there is defined in https://github.com/aschrab/dotfiles/blob/master/vim/autoload/autoformat.vim
It takes care of removing the `a` and `w` options from `formatoptions`
while in the header area.

Looks like I've been using that for ~13 years now, and I don't recall
having any issues with it.

[Wookey]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that emails
should be wrapped at 80 characters when they are sent should be dropped.

I admire your gumption for making such a proposal. :-)

A few years ago I would have objected strenously, as mutt+jed did not deal
well with long lines, and it was a pain to read. I have even been
known to berate people sending me such email.

However it seems to work fine these days so whilst long lines are harder to read, it's not a big deal.

I too am using the 'mutt in tmux/mosh on a remote machine' method to
read my mail. (I do really like the smart reflowing that emacs can do,
even with indented mails). The biggest problem with this method these
days is not text wraping, but enormously long multiline URLs,
especially when buried in incomprehensible modern HTML, and multipart
mails whern the text/plain part is actually just another copy of the
bloody HTML part - an infuriating thing that is becoming more common).

I know that others can find wrapped text difficult to deal with
because they are just not used to it these days. If you send an
article in in that form, it is likely to retain unwanted wrapping
linefeeds in the final version because taking them all out is hard for
normals (they just do it by hand in word/indesign/whatever and miss
the ones that happen to align linewraps)..

And in-line answered mail with indenting carets can also end up as
completely mashed garbage all flowed onto one big para at the far end
which is very hard indeed to read. This is other people's crappy
tools, but if one can make allowance for that without too much trouble
them one should.

So another vote for text=flowed here as a recommended default. And if
people want to use unwrapped lines, then I won't exactly like it, but
I'll manage. I already do for quite a lot of email.

This thread did, however, cause me to work out how to configure my mailer to
send format=flowed,

This is probably the most useful email in the thread. Cheers.
I have added
set text_flowed
to my mutt
but I think I need to know the equivalent to
au FileType mail setlocal formatoptions+=w
for
emacs particularly, but also zile, jed and mcedit (all of which get used from time to time).
Anyone know?

Wookey

[Bjørn Mork]

Post by Wookey
but I think I need to know the equivalent to
au FileType mail setlocal formatoptions+=w
for emacs particularly, but also zile, jed and mcedit (all of
which get used from time to time). Anyone know?

Set `use-hard-newlines' for emacs, according to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36821#8

Looks like there is a use-hard-newlines function to toggle the
setting in the current buffer. Let's test...



Bjørn

[Soren Stoutner]

Post by Soren Stoutner
The purpose of this email is to propose that the expectation that emails
should be wrapped at 80 characters when they are sent should be dropped.

This email has sparked an interesting discussion, which is what I was hoping for. So far, I
would summarize the points made as follows.

1. It would be really cool if all MUAs supported format=flowed, but they don’t, and we
shouldn’t require special software to interact with the Debian mailing lists.

2. Some MUAs don’t wrap text correctly with their default values, but so far they all seem
to have settings that support it.

3. Some people find it difficult to read long lines of text, but they can adjust their viewing
windows or display settings to make the lines shorter if they like.

4. Some people just don’t like change, but do not provide an argument for maintaining
things at the status quo.

Post by Soren Stoutner
"Wrap your lines at 80 characters or less for ordinary discussion. Lines
longer than 80 characters are acceptable for computer-generated output (e.g.,
ls -l).”
https://www.debian.org/MailingLists/

Given the above four points, I propose the line from the code of conduct quoted above be
changed to read:

“There is no expectation that emails sent to the mailing lists are wrapped by the sender at
a particular column, but those sending emails may wrap them if they choose.”

I like this wording because it does not prevent people from wrapping their emails if they
want. Although I think the superior options for the entire ecosystem would be that no
emails are wrapped by the sender, I can imagine there are users who need to interact with
other ecosystems which require wrapped emails, and forcing them to switch their settings
back and forth when communicating with Debian would be inconsiderate.

Therefore, I feel the above wording is fair for everyone.

[Holger Levsen]

Post by Soren Stoutner
Given the above four points, I propose the line from the code of conduct quoted above be

lol, 22h after proposing to change 20 year old habbits, you still agree with
your idea. i'm not impressed. also you seem to expect other people need to
explain the status quo to you, when you propose to change it. this is not how
things work.

and now that I'm writing this mail to this sad thread I also wont to applaud
your courage to break the rules in your very proposal to change them. (1st mail
of this thread.) - i mean, why have rules at all?

(the last paragraph is sarcasm.)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Make lying wrong again.

[Charles Plessy]

Post by Soren Stoutner

Post by Soren Stoutner
"Wrap your lines at 80 characters or less for ordinary discussion. Lines
longer than 80 characters are acceptable for computer-generated output (e.g.,
ls -l).”
https://www.debian.org/MailingLists/

Given the above four points, I propose the line from the code of conduct quoted above be
“There is no expectation that emails sent to the mailing lists are wrapped by the sender at
a particular column, but those sending emails may wrap them if they choose.”

Hi Soren,

thanks for the proposal! I also think that it is time to adjust our
standards.

I am not in favor of writing rules that say that there is no rule.
Maybe we can go one step further and just modify the rule about
complaining in private to be:

If you want to complain to someone that they wrapped or did not wrap
their lines, or that the sent you a carbon copy, do it privately.

Have a nice day,

Charles

[Jonathan Dowland]

Post by Soren Stoutner
1. It would be really cool if all MUAs supported format=flowed, but
they don’t, and we shouldn’t require special software to interact with
the Debian mailing lists.

format=flowed gracefully degrades for software which doesn't support it.
That software will simply not reformat the lines, so whatever wrapping
is in the original mail will be preserved. (You will see my text in
*this* mail wrapped at column 72, unless your client supports reflowing
and you've configured a different preference.) As such, recommending
format=flowed does not exclude people using software that doesn't yet
support it.

Post by Soren Stoutner

Post by Soren Stoutner
"Wrap your lines at 80 characters or less for ordinary discussion.
Lines longer than 80 characters are acceptable for computer-generated
output (e.g., ls -l).”
https://www.debian.org/MailingLists/

Given the above four points, I propose the line from the code of
“There is no expectation that emails sent to the mailing lists are
wrapped by the sender at a particular column, but those sending emails
may wrap them if they choose.”

This is effectively recommending nothing at all. If we were to accept
this change in spirit, I would suggest deleting the existing sentence
and not replacing it with something which basically says nothing. That
keeps the CoC as short as possible.

However, as stated above, since format=flowed gracefully degrades I
don't see a reason why we could not recommend it.

I also wonder whether a lower number than 80 might be a better default
for mobile clients. I haven't conducted any experiments.

[Soren Stoutner]

Post by Jonathan Dowland

Post by Soren Stoutner
“There is no expectation that emails sent to the mailing lists are
wrapped by the sender at a particular column, but those sending emails
may wrap them if they choose.”

This is effectively recommending nothing at all. If we were to accept
this change in spirit, I would suggest deleting the existing sentence
and not replacing it with something which basically says nothing. That
keeps the CoC as short as possible.

My concern with that is two-fold.

1. If we say nothing, there will, from time to time, be people who complain about emails
not being wrapped at a particular column. I think we need to be explicit that nobody
should feel they are authorized to complain about this on the mailing lists.

2. If we don’t explicitly state that it is OK if people do wrap their emails, from time to time
people will complain that some emails are wrapped. I think we need to make it explicit
that it is not OK to complain if other people do wrap their emails.

The CoC is a good place to list things it is not OK to complain to other people about if
there is a high likelihood they are going to do so unless it is explicit, especially when it
represents a change in long-standing behavior.

Post by Jonathan Dowland
However, as stated above, since format=flowed gracefully degrades I
don't see a reason why we could not recommend it.

I agree with that. I think the above statement includes that for people who already know
what format=flowed is (and have an MUA that can do so), but perhaps it should be more
explicit. Maybe the following.

“There is no expectation that emails sent to the mailing lists are wrapped by the sender at
a particular column, but those sending emails may wrap them if they choose. Users may
send in format=flowed if they desire and their MUA supports it.”

[Andrea Pappacoda]

Hi,

Post by Soren Stoutner
I agree with that. I think the above statement includes that for
people who already know what format=flowed is (and have an MUA that
can do so), but perhaps it should be more explicit. Maybe the
following.
“There is no expectation that emails sent to the mailing lists are
wrapped by the sender at a particular column, but those sending emails
may wrap them if they choose. Users may send in format=flowed if they
desire and their MUA supports it.”

I think that, if your MUA supports it, sending in format=flowed is
probably the best thing you can do (or, at least, that's my impression
- please correct me if I'm wrong). Hence, instead of saying that maybe,
if you want, you can send in f=f, the document should instead say that
users are highly encouraged to do so. It is not an issue if they don't,
but it's great if they do.

Bye!

[Marc Haber]

Post by Soren Stoutner
The CoC is a good place to list things it is not OK to complain to other people about if
there is a high likelihood they are going to do so unless it is explicit, especially when it
represents a change in long-standing behavior.

I am a bit concerned about puting such highly discussable things as
e-mail formatting in the CoC. The CoC is a document full of things that
a sensible person does not need to read because it is just a description
about what a sensible society expects from its members and any sane
person is going to to do anyway. It's a pity that it is needed (and
expected, nowadays) to put such things in writing.

So, please, let's do something like "Debian mailing list etiquette"
instead.

Greetings
Marc

[Soren Stoutner]

[off-list]

Post by Soren Stoutner
I agree with that. I think the above statement includes that for people who
already know what format=flowed is (and have an MUA that can do so), but
perhaps it should be more explicit. Maybe the following.
“There is no expectation that emails sent to the mailing lists are wrapped
by the sender at a particular column, but those sending emails may wrap
them if they choose. Users may send in format=flowed if they desire and
their MUA supports it.”

Hey Soren, speaking of format=flowed, it seems that your client sends
the plain text format in flowed format (i.e., with spaces at the end of
wrapped lines), but it doesn't set the content-type to f=f (i.e., you
text/plain; charset=utf-8; format=flowed".
Do you know if this is on purpose? Setting the appropriate content-type
parameter would allow clients to reflow text as desired :)

I have no idea. I did some searching for format=flowed and Kmail and didn’t find much
that is interesting, but I might not have looked deeply. Certainly, there is nothing in the
settings that indicate any controls for it.

One of the things that people who feel strongly about format=flowed can do would be to
open up feature requests with every MUA and ask that it be officially supported. I
considered doing so with Kmail, but decided against it because, as described in my
original email, I think it is incorrect from a technical perspective for the sending MUA to
determine where to wrap text. I think the correct behavior is for the sending MUA to not
wrap text at all unless the user decides to put in a hard line break. I believe all line
wrapping should be handled solely by the receiving MUA, which allows correct dynamic
wrapping on any size screen.

Format=flowed is being entirely driven by the belief that “We really want the sending MUA
to wrap text, but it creates horrible problems, so here is a cludge to work around it.” When
you get rid of the first part (really wanting the sending MUA to wrap text) suddenly there is
no need for the second part.

In 2025, any MUA that can’t figure out how to wrap receiving text deserves a bug report.

However, even though I feel that this is the correct approach, if Kmail had controls for
sending format=flowed I would be fine with that. So, if someone else wants to make the
pitch to the Kmail developers (which will probably require sending a patch if you really
want to see it merged), I would not dissuade them.

When I was searching, I came across the following blog post, which I thought was a bit
insightful.

https://www.fastmail.com/blog/format-flowed/

[Timo Röhling]

Hi,

Post by Soren Stoutner
Format=flowed is being entirely driven by the belief that “We really
want the sending MUA to wrap text, but it creates horrible problems, so
here is a cludge to work around it.”

I believe the idea is more like "We want the receiving MUA to do the
line wrapping, but we do not want to break MUAs which cannot do it
(yet)."

Post by Soren Stoutner
https://www.fastmail.com/blog/format-flowed/

Only a webmail provider can bitch about the complexity of text wrapping
and then proceed to recommend HTML, which is even more complex to render
and even more difficult to sanitize from malicious JavaScript. I guess
life is much simpler if you can rely on browser developers to do the
heavy lifting for you.


Cheers
Timo

[Marc Haber]

Post by Timo Röhling

Format=flowed is being entirely driven by the belief that “We really
want the sending MUA to wrap text, but it creates horrible problems, so
here is a cludge to work around it.”

I believe the idea is more like "We want the receiving MUA to do the
line wrapping, but we do not want to break MUAs which cannot do it
(yet)."

I am positively surprised that so many people in Debian still use mutt
(it's by far the most efficient way to handle large amounts of e-mail
including mailing lists"), so we need to cater for the fact that
e-mails are written in an entirely different software (an "editor"¹)
than it is consumed in.

Greetings
Marc

¹ to make it harder, the combination between mail reader and editor
multiplies. That was worse back when we had more than one
console-based mail reader.

[Jonas Smedegaard]

Quoting Marc Haber (2025-03-02 11:12:18)

Post by Marc Haber

Post by Timo Röhling

Post by Soren Stoutner
Format=flowed is being entirely driven by the belief that “We really
want the sending MUA to wrap text, but it creates horrible problems, so
here is a cludge to work around it.”

I believe the idea is more like "We want the receiving MUA to do the
line wrapping, but we do not want to break MUAs which cannot do it
(yet)."

I am positively surprised that so many people in Debian still use mutt
(it's by far the most efficient way to handle large amounts of e-mail
including mailing lists"), so we need to cater for the fact that
e-mails are written in an entirely different software (an "editor"¹)
than it is consumed in.

Good point!

Post by Marc Haber
¹ to make it harder, the combination between mail reader and editor
multiplies. That was worse back when we had more than one
console-based mail reader.

Not sure I follow your remark about "more than one console-based mail
reader" as something of the past. Previously in this thread I noticed
aerc mentioned, personally I use alot and might migrate to meli, all of
which are console-based MUAs (and all three arguably better integrated
with notmuch, for those interested in that).

- Jonas

[Blair Noctis]

On 02/03/2025 18:12, Marc Haber wrote:
(...)

Post by Marc Haber
I am positively surprised that so many people in Debian still use mutt
(it's by far the most efficient way to handle large amounts of e-mail
including mailing lists"), so we need to cater for the fact that
e-mails are written in an entirely different software (an "editor"¹)
than it is consumed in.

You gotta love having a central code forge which so many use,
but some object to.
Also a little less than one hundred ways of packaging.

Post by Marc Haber
Greetings
Marc
¹ to make it harder, the combination between mail reader and editor
multiplies. That was worse back when we had more than one
console-based mail reader.

Post by Blair Noctis
FWIW, I've enabled format=flowed after learning it in this thread, hopefully also giving those who would rather wrap some freedom (as to let it reflow, which effectively means to wrap, or not).

It's a bitch to reply to in mutt/vim.

Sorry to hear that.
I installed mutt and tried to reply to that email,
and mutt showed me the Content-Transfer-Encoding: base64 source.
I'm not sure if that's what you saw.
If you saw the decoded text,
I copied it into vim and vim seems to wrap it just fine.
Would you kindly show me how it looked on your side?

--
Sdrager,
Blair Noctis

[Marc Haber]

Post by Blair Noctis
I installed mutt and tried to reply to that email,
and mutt showed me the Content-Transfer-Encoding: base64 source.
I'm not sure if that's what you saw.
If you saw the decoded text,
I copied it into vim and vim seems to wrap it just fine.

Thankfully you usually don't copy the message into vim, but you hit
R)eply, L)ist Reply or reply A)ll and mutt fires up the Editor for you.

Post by Blair Noctis
Would you kindly show me how it looked on your side?

In the Editor, the long lines show up as long lines, with the
disadvantage that you either quote them not at all, or completely, or
have to go through intra-line editing to just leave what you want to
quote, and if it's a really long line vim will not show it at all
instead of partially.

That is surely something that one could adapt to, but I'd hate having
to.

Notes and Outlook have done incredible damage to E-Mail culture,
introducing Top-Posting as the widely accepted (but totally inferior)
way to have discussions in e-mail. Please let us consider using a method
that doesn't make discussions harder.

Greetings
Marc

[Blair Noctis]

(...)

Post by Soren Stoutner
https://www.fastmail.com/blog/format-flowed/

Only a webmail provider can bitch about the complexity of text wrapping and then proceed to recommend HTML, which is even more complex to render and even more difficult to sanitize from malicious JavaScript. I guess life is much simpler if you can rely on browser developers to do the heavy lifting for you.

FWIW, you can use their service via IMAP and SMTP. Open source webmails also exist.

Text wrapping is complex, and yes, life is much simpler relying on browsers doing the heavy lifting, maybe because it's so hard to do with non-browser libraries.

JavaScript seems to be not allowed in most MUAs (as per https://en.wikipedia.org/wiki/Comparison_of_email_clients), notably exceptions include Thunderbird (TIL! Can be disabled via javascript.enabled in about:config) and Outlook Express (which I assume most of you wouldn't use).

--
Sdrager,
Blair Noctis

[Marc Haber]

Post by Blair Noctis
Open source webmails also exist.

"When you're 10 out of 10 but it's your CVSS score".

Greetings
Marc

[Andrea Pappacoda]

Il giorno sab 1 mar 2025 alle 09:48:36 +01:00:00, Timo Röhling

Post by Timo Röhling

Format=flowed is being entirely driven by the belief that “We
really want the sending MUA to wrap text, but it creates horrible
problems, so here is a cludge to work around it.”

Quite the opposite!

Post by Timo Röhling
I believe the idea is more like "We want the receiving MUA to do the
line wrapping, but we do not want to break MUAs which cannot do it
(yet)."

In addition to what Timo said, format=flowed also resolves some other
issues like how to unambiguously identifying quoted lines from lines
starting with ">", and others. HTML also solves the same issues, and
more, but introduces its own problems.

Post by Timo Röhling

https://www.fastmail.com/blog/format-flowed/

Rather than "the little standard that couldnʼt quite make it", I'd
call this article "the standard that we (Fastmail) wanted to support,
but couldn't make it". More than highlighting any particular issue with
format=flowed itself, it just gives their rationale for not supporting
it. Of course, if all you do is writing and receiving HTML emails in an
HTML web application, focusing on plain text formats makes little
sense. It does not look relevant for our mailing lists, though.

[Soren Stoutner]

Post by Soren Stoutner
https://www.fastmail.com/blog/format-flowed/

Rather than "the little standard that couldnÊŒt quite make it", I'd
call this article "the standard that we (Fastmail) wanted to support,
but couldn't make it". More than highlighting any particular issue with
format=flowed itself, it just gives their rationale for not supporting
it. Of course, if all you do is writing and receiving HTML emails in an
HTML web application, focusing on plain text formats makes little
sense. It does not look relevant for our mailing lists, though.

I am not an expert on format=flowed, so I can’t vouch for the following myself, but I
thought it was interesting that the article above linked to the following:

https://wiki.openstack.org/wiki/MailingListEtiquette#Thunderbird

Which has instructions for disabling format=flowed, saying it caused problems. I’m not
sure how much OpenStack represents general consensus for what works best on mailing
lists, but it is at least one data point.

[Jeremy Stanley]

On 2025-03-03 10:35:32 -0700 (-0700), Soren Stoutner wrote:
[...]

Post by Soren Stoutner
I am not an expert on format=flowed, so I can’t vouch for the
following myself, but I thought it was interesting that the
https://wiki.openstack.org/wiki/MailingListEtiquette#Thunderbird
Which has instructions for disabling format=flowed, saying it
caused problems. I’m not sure how much OpenStack represents
general consensus for what works best on mailing lists, but it is
at least one data point.

I'm the main list admin for the OpenStack mailing lists these days,
and I haven't observed it causing any issues. Also, as the main
admin for that wiki, I feel compelled to point out the article you
linked has included that disclaimer about Thunderbird's
format=flowed problems since before it was migrated from MoinMoin to
Mediawiki over 13 years ago, so it very well could be outdated.
Based on the context in the last sentence of that section, I think
it may have been something to do with inlined diffs/patches being
malformed by the client with that option enabled, so I wouldn't be
surprised if it's been fixed in the decade+ since.

I'll go ahead and annotate the recommendation to suggest it's
probably outdated, thanks for pointing that out!

[Soren Stoutner]

Post by Jeremy Stanley
[...]

Post by Soren Stoutner
I am not an expert on format=flowed, so I can’t vouch for the
following myself, but I thought it was interesting that the
https://wiki.openstack.org/wiki/MailingListEtiquette#Thunderbird
Which has instructions for disabling format=flowed, saying it
caused problems. I’m not sure how much OpenStack represents
general consensus for what works best on mailing lists, but it is
at least one data point.

I'm the main list admin for the OpenStack mailing lists these days,
and I haven't observed it causing any issues. Also, as the main
admin for that wiki, I feel compelled to point out the article you
linked has included that disclaimer about Thunderbird's
format=flowed problems since before it was migrated from MoinMoin to
Mediawiki over 13 years ago, so it very well could be outdated.
Based on the context in the last sentence of that section, I think
it may have been something to do with inlined diffs/patches being
malformed by the client with that option enabled, so I wouldn't be
surprised if it's been fixed in the decade+ since.
I'll go ahead and annotate the recommendation to suggest it's
probably outdated, thanks for pointing that out!

Good to know.

[Otto Kekäläinen]

Hi!

“There is no expectation that emails sent to the mailing lists are wrapped by the sender at a particular column, but those sending emails may wrap them if they choose.”
I like this wording because it does not prevent people from wrapping their emails if they want. Although I think the superior options for the entire ecosystem would be that no emails are wrapped by the sender, I can imagine there are users who need to interact with other ecosystems which require wrapped emails, and forcing them to switch their settings back and forth when communicating with Debian would be inconsiderate.
Therefore, I feel the above wording is fair for everyone.

I think this a reasonable suggestion by Soren. Alternatively, Charles
suggestion to completely remove mentions of line wrapping requirement
from the "Code of conduct" section at
https://www.debian.org/MailingLists/ would also work.

All those docs and web pages are read by new people interested in
contributing to Debian, and I am glad to see people reviewing,
updating and cleaning them up.

This thread about line wrapping also shows that there are many with
two or more decades of experience in Debian, who have over the years
formed their own highly optimized workflows and email client and text
editor settings which diverge from what "mainstream" today considers
easy or optimal. I am hugely grateful for people who have contributed
to Debian for decades and I hope to see them continue to contribute
for decades to come. At the same time I wonder how we can narrow the
evident cultural gap between the Mutt user generation and newer web
email generation users, which also manifests in other areas of
workflow preferences as we have seen in discussions about email vs web
interface for bug reports.

[Leandro Cunha]

Post by Otto Kekäläinen
Hi!

“There is no expectation that emails sent to the mailing lists are wrapped by the sender at a particular column, but those sending emails may wrap them if they choose.”
I like this wording because it does not prevent people from wrapping their emails if they want. Although I think the superior options for the entire ecosystem would be that no emails are wrapped by the sender, I can imagine there are users who need to interact with other ecosystems which require wrapped emails, and forcing them to switch their settings back and forth when communicating with Debian would be inconsiderate.
Therefore, I feel the above wording is fair for everyone.

I think this a reasonable suggestion by Soren. Alternatively, Charles
suggestion to completely remove mentions of line wrapping requirement
from the "Code of conduct" section at
https://www.debian.org/MailingLists/ would also work.
All those docs and web pages are read by new people interested in
contributing to Debian, and I am glad to see people reviewing,
updating and cleaning them up.
This thread about line wrapping also shows that there are many with
two or more decades of experience in Debian, who have over the years
formed their own highly optimized workflows and email client and text
editor settings which diverge from what "mainstream" today considers
easy or optimal. I am hugely grateful for people who have contributed
to Debian for decades and I hope to see them continue to contribute
for decades to come. At the same time I wonder how we can narrow the
evident cultural gap between the Mutt user generation and newer web
email generation users, which also manifests in other areas of
workflow preferences as we have seen in discussions about email vs web
interface for bug reports.

Accordingly! :)

[IOhannes m zmölnig]

I think this a reasonable suggestion by Soren. […]

Incidentally, the suggestion is good as illegible on a

I think I'm misunderstanding something here, because - assuming you attached the screenshot as an example of an as "good as illegible" email - *your* email incidentally looks just as illegible to me. At least, it is awkward to read (formatting wise).



I'm on K-9 right now, so sorry if my formatting is bonkers as well (I have no idea how I could adjust it)


mfh.her.fsr
IOhannes

[Marc Haber]

Post by Soren Stoutner
I started thinking about this a few weeks ago when I received an email from a Debian Developer complaining that replies from my email client (KMail) looked odd because they truncated quoted lines in a way that did not lay out pleasingly. This was because I had set KMail to wrap lines at 80 characters.

I have been using Kmail for years without requiring my communication
partners to change their habits.

I am one of those mutt dinosaurs. While mutt displays e-mails with long
lines just fine, handing them over to the editor for answering leaves
the long lines to the editor. If I wanted just to quote part of your
message above, or even insert my comments between two of your sentences,
that would be manual work.

Can this be done even better?

Or is this just another discussion whether we should continue using
mailing lists? I mean, Internet humanity hasn't been able to settle on
one kind of quoting referenced messages (with the in my opinion sensible
way having lost to the useless top posting method).

Post by Soren Stoutner
However, from a technical perspective, having the *sending* program decide where line breaks should be in an email doesn’t seem like the correct approach to me because, 1) the sending program does not know the screen width of the receiving program, and 2) there is large variability in the screen width of receiving devices, including cell phones who are often less than 80 characters wide.

The sending program also knows more what the writing person wants to
say.

Post by Soren Stoutner
I have composed this email without an arbitrary column wrap, so that those receiving it can see how it is handled by their various clients and devices.

Clumsy to read, impossible to reply to.

Greetings
Marc

[Jonathan Dowland]

Post by Soren Stoutner
I have composed this email without an arbitrary column wrap, so that
those receiving it can see how it is handled by their various clients
and devices.

I didn't notice (until Marc pointed it out) because my client (aerc)
re-wraps mails, even non-format=flowed ones, although I think there's a
risk the process could corrupt the message. I haven't spotted that
happening yet.

I double-checked whether your message was format=flowed or not, and
noticed you sent it multipart with HTML, which (given the topic) I found
amusing.

[Soren Stoutner]

Post by Jonathan Dowland

Post by Soren Stoutner
I have composed this email without an arbitrary column wrap, so that
those receiving it can see how it is handled by their various clients
and devices.

I didn't notice (until Marc pointed it out) because my client (aerc)
re-wraps mails, even non-format=flowed ones, although I think there's a
risk the process could corrupt the message. I haven't spotted that
happening yet.
I double-checked whether your message was format=flowed or not, and
noticed you sent it multipart with HTML, which (given the topic) I found
amusing.

I think that is probably Kmail’s default. Nothing in this discussion is about HTML vs. plain
text. I don’t really mind if Kmail sends an HTML part as long as it also sends a plain text
part, and it probably makes life easier for a lot of the people I communicate with outside
of Debian circles.

As a funny side note, when I first started actively contributing to Debian I opened a
lengthy bug report. I started typing it in reportbug, but the complexity of the report and
the desire for spell checking caused me to compose it in Kate instead. When I was done I
copied and pasted it into the open reportbug and sent it off.

The resulting text was not wrapped. I didn’t think anything about it at the time, but I got a
complaint from someone responding to the bug report saying it was hard to quote my
HTML text. I thought to myself, “I didn’t know reportbug produced HTML text?” Of course,
it hadn’t. Rather, the person who was having problems with unwrapped text assumed it
was some sort of HTML problem.

It was because of that I set Kmail to wrap text at 80 columns. And I make sure and
manually wrap text in reportbug. Until now, when this itch got big enough I thought it
was time it should be scratched.

[Soren Stoutner]

On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss

Looks pretty awful to me. Screenshot attached.

Yes, the screenshot you sent shows how ugly it is when my email client
wraps sending emails at 80 columns. It is for this reason I think we
ought to get rid of that and simply let the receiving MUA handle all
wrapping.

[Philipp Kern]

On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss

Looks pretty awful to me. Screenshot attached.

Yes, the screenshot you sent shows how ugly it is when my email client
wraps sending emails at 80 columns. It is for this reason I think we
ought to get rid of that and simply let the receiving MUA handle all
wrapping.

I love that people are saying that their clients don't support
format=flowed and thus we can't mandate them but then we make it the
problem of the receiver that their MUA is not wrapping properly.

Mine doesn't wrap properly either, especially on wide screens. Neither
Thunderbird nor Roundcube. 80 characters are perfectly readable,
long-lines are increasingly annoying to read.

I can see how that part is a "me" problem. But it also worked perfectly
fine before.

Kind regards
Philipp Kern

[Soren Stoutner]

Post by Philipp Kern

Post by Soren Stoutner
On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss

Looks pretty awful to me. Screenshot attached.

Yes, the screenshot you sent shows how ugly it is when my email client
wraps sending emails at 80 columns. It is for this reason I think we
ought to get rid of that and simply let the receiving MUA handle all
wrapping.

I love that people are saying that their clients don't support
format=flowed and thus we can't mandate them but then we make it the
problem of the receiver that their MUA is not wrapping properly.
Mine doesn't wrap properly either, especially on wide screens. Neither
Thunderbird nor Roundcube. 80 characters are perfectly readable,
long-lines are increasingly annoying to read.
I can see how that part is a "me" problem. But it also worked perfectly
fine before.

As I wrote in another part of this thread, in 2025 any MUA that can’t wrap received text to
the preference of the viewer deserves a bug filed against that MUA. For example, every
graphical MUA of which I am aware (like Thunderbird and Roundcube, which you mention)
can wrap text to the desired length by resizing the viewable window. If your does not, I
would recommend filing a bug report against your MUA.

[Roger Lynn]

Post by Philipp Kern
Mine doesn't wrap properly either, especially on wide screens. Neither
Thunderbird nor Roundcube. 80 characters are perfectly readable,
long-lines are increasingly annoying to read.
I can see how that part is a "me" problem. But it also worked perfectly
fine before.

As I wrote in another part of this thread, in 2025 any MUA that can’t wrap received text to
the preference of the viewer deserves a bug filed against that MUA. For example, every
graphical MUA of which I am aware (like Thunderbird and Roundcube, which you mention)
can wrap text to the desired length by resizing the viewable window. If your does not, I
would recommend filing a bug report against your MUA.

In the common layout used by most graphical MUAs that I have seen, making
the window narrow enough to wrap text at a sensible line length results in
Subject, From and Date columns that are too narrow to read. I have just
tried an alternative layout in Seamonkey (nee Mozilla) that puts the folder,
thread and message panes side by side, which does work (especially if you
have a large monitor or you are happy for it to use the full width), but
does feel very odd. I expect that Thunderbird has a similar setting (and in
reply to Blair Noctis, I am sure that Thunderbird properly supports
format=flowed if properly configured (I have disabled it in Seamonkey, but
am considering re-enabling as a result of this thread)).

[Jonathan Dowland]

On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss

Looks pretty awful to me. Screenshot attached.

Yes, the screenshot you sent shows how ugly it is when my email client
wraps sending emails at 80 columns. It is for this reason I think we
ought to get rid of that and simply let the receiving MUA handle all
wrapping.

Where's Mason's email to which you are replying? I can't see it on the
list.

[Stephan Verbücheln]

Are you aware that you are sending HTML messages the whole time?

Are you aware that in those HTML parts, the source code is limited to
80 characters per line?

Have you ever noticed that this is also the case for base64-encoded
binary attachments?

Are you aware that even the text/plain section of your email is limited
to 80 characters in the source code?

This is not only about display preferences in Mail User Agents.

Regards
Stephan

[Soren Stoutner]

Post by Stephan Verbücheln
Are you aware that you are sending HTML messages the whole time?

Yes, as I mentioned elsewhere in this thread, the current version of Kmail defaults to
sending both plain text and HMTL parts for every email.

Also, as I mentioned elsewhere in this thread, this is not a discussion about the merits of
HTML vs plain text. As long as emails to the mailing list contain a plain text part, I know of
no problem caused by them also containing an HTML part, which the receiving MUA is
welcome to ignore.

Post by Stephan Verbücheln
Are you aware that in those HTML parts, the source code is limited to
80 characters per line?
Have you ever noticed that this is also the case for base64-encoded
binary attachments?
Are you aware that even the text/plain section of your email is limited
to 80 characters in the source code?

Yes, the original email I sent starting this discussion was not wrapped at any column. I did
so so that everyone can see how their MUAs render such emails.

https://lists.debian.org/debian-devel/2025/02/msg00302.html

All of the subsequent emails I have sent as part of this discussion have been wrapped at
80 characters inline with the current mailing list code of conduct.

https://www.debian.org/MailingLists/#codeofconduct

I feel that it is important I follow the current code of conduct as I advocate for its change.

[Henrik Ahlgren]

Post by Soren Stoutner
All of the subsequent emails I have sent as part of this
discussion have been wrapped at 80 characters inline with the
current mailing list code of conduct.

If I'm not mistaken, your emails (at least this one I am replying
to) utilize Format=Flowed (in the text/pain part) as outlined in
RFC 2646. However, the "logical" lines are wrapped at
approximately 120 characters instead of the recommended 80
characters per the RFC. Nonetheless, the actual on-wire lines are
under 80 characters, encoded with quoted-printable.

F=F is a promising concept, but it can be surprisingly challenging to
implement correctly, even when it seems trivial.

[Andrea Pappacoda]

Hi Henrik,

Post by Henrik Ahlgren

Post by Soren Stoutner
All of the subsequent emails I have sent as part of this
discussion have been wrapped at 80 characters inline with the
current mailing list code of conduct.

If I'm not mistaken, your emails (at least this one I am replying
to) utilize Format=Flowed (in the text/pain part) as outlined in
RFC 2646.

No, he's not. Here's the relevant part of the raw message:

[...]
Content-Transfer-Encoding: 7Bit
From: Soren Stoutner <***@debian.org>
To: debian-***@lists.debian.org
Date: Mon, 03 Mar 2025 13:38:16 -0700
Message-ID: <***@soren-desktop>
Organization: Debian
MIME-Version: 1.0

This is a multi-part message in MIME format.

--nextPart4248614.FYXLhVEQL0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
[...]

As you can see, the Content-Type header has no Format parameter. Yeah,
(decoded) lines end with ' ' (ASCII space), but with no Format parameter
set to Flowed, they have no special meaning.

Post by Henrik Ahlgren
Nonetheless, the actual on-wire lines are under 80 characters, encoded
with quoted-printable.

Just to be clear: this has nothing to do with Format=Flowed. The
Content-Transfer-Encoding does not bind the Content-Type, nor vice
versa.

Post by Henrik Ahlgren
F=F is a promising concept, but it can be surprisingly challenging to
implement correctly, even when it seems trivial.

Is it? I wrote a simple flowed-to-html converter in something like 50
lines of C. It may not be sophisticated, but to me it seems to work as
expected. As for composing, simple editors like Vim can produce
compliant text with a one-line configuration option.

[Henrik Ahlgren]

Post by Andrea Pappacoda
As you can see, the Content-Type header has no Format parameter.
Yeah, (decoded) lines end with ' ' (ASCII space), but with no
Format parameter set to Flowed, they have no special meaning.

I stand corrected; I mistakenly interpreted f=f there. It seems
expectation bias played tricks on my mind. It seems that KMail (?)
has significant issues with f=f implementation.

Post by Andrea Pappacoda

Post by Henrik Ahlgren
F=F is a promising concept, but it can be surprisingly
challenging to implement correctly, even when it seems
trivial.

Is it? I wrote a simple flowed-to-html converter in something
like 50 lines of C. It may not be sophisticated, but to me it
seems to work as expected. As for composing, simple editors
like Vim can produce compliant text with a one-line
configuration option.

The specification is straightforward, yet many MUAs mishandle it,
particularly in edge cases. For example, Gnus exhibits numerous
peculiar bugs. In the last message by me you replied to, the final
paragraph fails to soft-wrap, unlike the preceding one, and Gnus
itself renders it as part of the same paragraph (unlike e.g.
Evolution). This indicates problems in both encoding and decoding.
I can only guess how this email will end up after I've sent it. I
really can't decide if I should use f=f or not.

Additionally, some messages contain sections that should never be
soft-wrapped, such as diffs. I'm uncertain whether many MUAs offer
a smooth user interface to designate which paragraphs should be
hard-wrapped. At least Gnus (message.el) does not.

[Jonathan Dowland]

Post by Henrik Ahlgren
Additionally, some messages contain sections that should never be
soft-wrapped, such as diffs. I'm uncertain whether many MUAs offer a
smooth user interface to designate which paragraphs should be
hard-wrapped. At least Gnus (message.el) does not.

An inline-diff will not be wrapped unless any of the lines ends with a
space character. Of course, sometimes, they will; in which case, for
that email, the user should either not use format=flowed, or attach the
diff instead. Evidently this is not ideal. I hazard that inline-diffs is
a special-case rather than a general-case of email, these days.

[Stephan Verbücheln]

Post by Soren Stoutner
Also, as I mentioned elsewhere in this thread, this is not a
discussion about the merits of HTML vs plain text.  As long as emails
to the mailing list contain a plain text part, I know of no problem
caused by them also containing an HTML part, which the receiving MUA
is welcome to ignore.

The rules say “Please don't send your messages in HTML,” they do not
say “Please also add plain text to your messages.”

It bloats up the message.

But the more serious problem: Everyone actually has to verify that both
message parts have the same content for any important message, which
are both signed by PGP.

Post by Soren Stoutner
All of the subsequent emails I have sent as part of this discussion
have been wrapped at 80 characters inline with the current mailing
list code of conduct.

They are wrapped in a silly and broken way if you take a look at the
message source.

Regards

[Soren Stoutner]

Post by Stephan Verbücheln

Post by Soren Stoutner
Also, as I mentioned elsewhere in this thread, this is not a
discussion about the merits of HTML vs plain text. As long as emails
to the mailing list contain a plain text part, I know of no problem
caused by them also containing an HTML part, which the receiving MUA
is welcome to ignore.

The rules say “Please don't send your messages in HTML,” they do not
say “Please also add plain text to your messages.”
It bloats up the message.
But the more serious problem: Everyone actually has to verify that both
message parts have the same content for any important message, which
are both signed by PGP.

Interesting. I guess that text could be interpreted as “Do not send an HTML part, even if
you also send a plain text part.”

If that is the general understanding of the meaning of that section, then I think we ought
to start a separate discussion about changing the text to be explicit that it is OK to send an
HTML part as long as there is also a plain text part. However, I would appreciate it if this
discussion were not hijacked to discuss HTML vs. plain text. This discussion is only about
whether sending MUAs should be required to wrap plain text at a particular column.

Post by Stephan Verbücheln

Post by Soren Stoutner
All of the subsequent emails I have sent as part of this discussion
have been wrapped at 80 characters inline with the current mailing
list code of conduct.

They are wrapped in a silly and broken way if you take a look at the
message source.

I agree. Having the sending MUA wrap text creates problems, even with efforts like
format=flowed that try to hint to the receiving MUA how to unwrap the text. Hence, I
propose that we change the expectation so that the sending MUA is not expected to wrap
text. I believe it is the only solution that makes technical sense because 1) the sending
MUA does not know the screen width of the receiving device, and 2) different receiving
devices and users have wildly different width needs, and there is no single column width
the sending MUA can use that works well on all receiving devices.

[Russ Allbery]

I agree. Having the sending MUA wrap text creates problems, even with
efforts like format=flowed that try to hint to the receiving MUA how to
unwrap the text.

I am getting nerd-sniped here and really should continue ignoring this
thread, but just for the record:

* You are not using format=flowed. (Some other people on this thread are,
but your messages are not.) You are sending your messages as simple
text/plain. You or your MUA is adding a space to the end of each line as
if the message were format=flowed, but it is not marked format=flowed,
so none of that is working.

* You are not wrapping the text part of your messages at 80 columns
currently. You are hard-wrapping them at something like 90 or 95
columns, which is strictly worse than *either* wrapping them under 80
columns *or* not wrapping them at all.

I don't think this was intentional, to be clear, but I believe your MUA is
not working the way that you think it's working.

[Jeremy Sowden]

[snip] I am getting nerd-sniped here [snip]

I did not know that there was a word for this. I have learnt
something fun to-day. Thanks, Russ (and Randall). :)

J.

[Holger Levsen]

Post by Jeremy Sowden

[snip] I am getting nerd-sniped here [snip]

I did not know that there was a word for this. I have learnt
something fun to-day. Thanks, Russ (and Randall). :)

xkcd.com/356 :)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Everyone is entitled to their own opinion, but not their own facts.

[Soren Stoutner]

Post by Russ Allbery

I agree. Having the sending MUA wrap text creates problems, even with
efforts like format=flowed that try to hint to the receiving MUA how to
unwrap the text.

I am getting nerd-sniped here and really should continue ignoring this
* You are not using format=flowed. (Some other people on this thread are,
but your messages are not.) You are sending your messages as simple
text/plain. You or your MUA is adding a space to the end of each line as
if the message were format=flowed, but it is not marked format=flowed,
so none of that is working.

I agree. Kmail does not have controls for format=flowed and does not advertise that it
supports it, although it appears to have adopted part of the standard.

As I have written in other parts of this discussion, I do not feel that format=flowed is the
solution, although I have no objection if other people send emails to the mailing list that
are format=flowed.

Post by Russ Allbery
* You are not wrapping the text part of your messages at 80 columns
currently. You are hard-wrapping them at something like 90 or 95
columns, which is strictly worse than *either* wrapping them under 80
columns *or* not wrapping them at all.
I don't think this was intentional, to be clear, but I believe your MUA is
not working the way that you think it's working.

That is interesting. I have Kmail set to wrap at 80 columns. However, it wouldn’t surprise
me if Kmail has some bug in this regard.

Please feel free to submit a bug report to Kmail if you like.

From my perspective, the correct result is for this discussion to reach the consensus that
there is no expectation that sending MUAs wrap text, at which point I will disable the
setting in Kmail to wrap text at 80 columns and, even if Kmail has some sort of bug that is
converting 80 columns to 90 or 95 columns, it should never manifest again in any email
that I send.

[Stephan Verbücheln]

However, I would appreciate it if this discussion were not hijacked
to discuss HTML vs. plain text.

In case we define any new rules, it has to cover both.

That is interesting.  I have Kmail set to wrap at 80 columns. 
However, it wouldn’t surprise me if Kmail has some bug in this
regard.

No one asked you to (manually) wrap on the editor level. You should
wrap on the protocol level, which is a different thing.

Now with your setup, you are doing both at the same time with silly
results. Please take a look at the source code of your messages.

As someone else already pointed out, your editor-level line length is
around 92 characters, and then each 92 character line is split into two
lines with 78 and around 14 characters. It is also wrapping in the
middle of words.

Your setup is broken for any convention.

Regards

[Jonathan Dowland]

Post by Soren Stoutner
From my perspective, the correct result is for this discussion to
reach the consensus that there is no expectation that sending MUAs
wrap text

I don't think we've reached that consensus in this discussion.

[Jonathan Dowland]

Hence, I propose that we change the expectation so that the sending
MUA is not expected to wrap text.

In which case, how can the receiving MUA know which lines are wrappable
and which are not? Related, how can the sending MUA signal which lines
are wrappable and which are not?

[Soren Stoutner]

Post by Jonathan Dowland

Hence, I propose that we change the expectation so that the sending
MUA is not expected to wrap text.

In which case, how can the receiving MUA know which lines are wrappable
and which are not? Related, how can the sending MUA signal which lines
are wrappable and which are not?

This is an interesting question based on a presumption that I didn’t know was possible. In
a plain text email, is it possible to indicate that certain lines are not wrappable? I know it is
possible in an HTML email, but I was unaware of any way of doing so in a plain text email
(at least, any generally accepted standard).

For example, on my cell phone I use Thunderbird as my MUA. In portrait mode on my
device text wraps at about 40 columns. Are you saying that you can send a plain text
email in such a way that Thunderbird or any other MUA on a cell phone will force scrolling
left and right to read the lines instead of having the MUA wrap them at the edge of the
screen?

[Charles Plessy]

This is an interesting question based on a presumption that I didn’t know was
possible. In a plain text email, is it possible to indicate that certain
lines are not wrappable?

I am surprised nobody has mentionned support (or lack of support) of
text/markdown at this point...

Have a nice day,

[Jeremy Stanley]

On 2025-03-05 08:52:22 +0900 (+0900), Charles Plessy wrote:
[...]

Post by Charles Plessy
I am surprised nobody has mentionned support (or lack of support) of
text/markdown at this point...

[...]

Surely you mean troff/groff?
.Pp
.Bd It's \fIthe best\fP!

;)

[Soren Stoutner]

Post by Jeremy Stanley
[...]

Post by Charles Plessy
I am surprised nobody has mentionned support (or lack of support) of
text/markdown at this point...

[...]
Surely you mean troff/groff?
.Pp
.Bd It's \fIthe best\fP!
;)

Thank you. I needed that smile today.

[Jonathan Dowland]

This is an interesting question based on a presumption that I didn’t
know was possible. In a plain text email, is it possible to indicate
that certain lines are not wrappable?

Yes. That's exactly what format=flowed does. Line ends in space?
Wrappable. Line doesn't? Not wrappable.

For example, on my cell phone I use Thunderbird as my MUA. In
portrait mode on my device text wraps at about 40 columns. Are you
saying that you can send a plain text email in such a way that
Thunderbird or any other MUA on a cell phone will force scrolling left
and right to read the lines instead of having the MUA wrap them at the
edge of the screen?

Force, no. Thunderbird on Android might choose to wrap lines that are
not marked as wrappable. As a sender, the best I can do is advise.

[Jeremy Stanley]

Post by Jonathan Dowland

Post by Soren Stoutner
This is an interesting question based on a presumption that I didn’t
know was possible. In a plain text email, is it possible to
indicate that certain lines are not wrappable?

Yes. That's exactly what format=flowed does. Line ends in space?
Wrappable. Line doesn't? Not wrappable.

[...]

Semantics maybe, but that's not how I interpret the format=flowed
spec (or perhaps the question).

Having a space at the end of a line indicates the line has been
soft-wrapped by the sender, so from the reader's perspective the
line should be logically (re)combined with the line following it.
That doesn't exactly say whether or not a line *can* be wrapped, but
rather that it was preemptively soft-wrapped and so can be
automatically "unwrapped" or "rewrapped" after concatenating
subsequent lines.

Absence of a space at the line end doesn't say not to wrap that
line, but merely not to combine it with the line that follows. The
line itself can still be wrapped as needed if it exceeds the
client's preferred length.

[Andrey Rakhmatullin]

If I were to write, say, a Thunderbird extension that forcibly unwraps
text I receive, regardless of whether format=flowed was specified,
what would be the implication?
For sake of argument:- If this re-wrapping is purely client side and
happens after PGP verification, incoming mail could still show as
verified (but it may look slightly different)- I could toggle this on/off
per message, so that I can still write inline replies based on the
original message's formatting

[Henrik Ahlgren]

For sake of argument:- If this re-wrapping is purely client side and
happens after PGP verification, incoming mail could still show as
verified (but it may look slightly different)- I could toggle this
on/off per message, so that I can still write inline replies based
on the original message's formatting

There are many other forms of text where we can't merely consider them
as paragraphs of prose. For instance, in technical mailing lists,
snippets of source code are quite common. Additionally, one may
encounter elements like postal addresses or poetry, where (hard)
newlines matter for proper formatting. Some individuals still favor the
traditional practice of indenting paragraphs rather than the "block
paragraph" style that predominates in today's email culture (most likely
due to challenges in this exact issue).

It is essential to have a method for distinguishing between hard and
soft newlines if you want to reflow text properly.

[Jonathan Dowland]

Post by Henrik Ahlgren
It is essential to have a method for distinguishing between hard and
soft newlines if you want to reflow text properly.

Agreed! And, as Jeremy Stanley points out in another msg, this is not
*quite* what format=flowed promises.

[Jeremy Stanley]

Post by Jonathan Dowland

Post by Henrik Ahlgren
It is essential to have a method for distinguishing between hard
and soft newlines if you want to reflow text properly.

Agreed! And, as Jeremy Stanley points out in another msg, this is
not *quite* what format=flowed promises.

Eh, it's pretty close though. The gist is that a <space><linebreak>
sequence is meant to represent a soft line break, while <linebreak>
not preceded by <space> is a regular hard line break. (Whether
<linebreak> is <CR><LF> or bare <LF> depends on whether you're
considering it at the SMTP layer or MUA/editor of course.)

My earlier message was more contesting the suggestion that absence
of a soft line break implies the line should not be *wrapped* into
multiple shorter lines by the client (i.e. the preformatted text
case), which is incorrect; rather it means that line should not be
logically *combined* with the next (treat it as a hard line break).

So it basically does provide a means of encoding the soft vs. hard
line break distinction, it's just that soft and hard line breaks
don't tell you what can be wrapped, they tell you what can be
combined. The underlying assumption is that every line can be
wrapped, but not all lines can be combined. This is also at the
heart of the lack of suitability for preformatted text, e.g. inline
patch diffs.

Maybe part of the confusion is that some of us define the term "line
wrapping" differently?

[The Wanderer]

Hi all,

Post by Soren Stoutner
However, from a technical perspective, having the *sending* program
decide where line breaks should be in an email doesn’t seem like
the correct approach to me because, 1) the sending program does not
know the screen width of the receiving program, and 2) there is
large variability in the screen width of receiving devices,
including cell phones who are often less than 80 characters wide.

There's plenty of discussion about format=flowed elsewhere in this
thread, but unfortunately it never caught on. This got me thinking
though: why do email clients *have* to show hard-wrapped text as-is?
If I were to write, say, a Thunderbird extension that forcibly
unwraps text I receive, regardless of whether format=flowed was
specified, what would be the implication?

At my workplace, I am obliged to use Outlook.

By default, Outlook seems to do exactly that, on the recipient and
viewing side: it leaves the actual representation on-disk etc. alone,
but if it sees consecutive non-blank lines (I'm guessing the criterion
is actually "has something other than whitespace at the start of the
line"), it will fold those lines together into a single line (with the
division point represented by, as far as I can see, a single space) at
rendering time. There seems to be nothing you can do, as the sender, to
affect this behavior for the recipient - not short of using *double*
newlines, turning each "line" into its own paragraph.

There seem to be some special rules relating to punctuation (if the
previous line ends with a period, the next one won't be folded into the
same line; if the new line begins with a '>', the two lines won't be
folded together; I've also seen cases where the new line begins with a
single word followed by a period and a close-paren get the new line not
folded in to the previous), but I don't have a full handle on those, and
the 100-foot view of the behavior remains the same.

This sometimes makes no difference, and sometimes drives me *batty*,
especially given how much effort I put in to manually adding those
hard-line-breaks in all the mails I have to compose in Outlook (since it
won't add them itself).

There *is* a setting which can disable this behavior; I don't remember
what it is, except that it might be (or be a subset of) the "read E-mail
as plain text" setting which they designate as being a security option.
That setting is per-client, however.

...which has the effect that the same person can see the same mail
rendered differently when reading it on different devices. I personally
find that to be a negative, but others may well find it to be a
positive.

[Giuseppe Sacco]

Hello James,

Hi all,

Post by Soren Stoutner
I started thinking about this a few weeks ago when I received an email
from a Debian Developer complaining that replies from my email client
(KMail) looked odd because they truncated quoted lines in a way that did
not lay out pleasingly.  This was because I had set KMail to wrap lines
at 80 characters.

I see this too with a lot of ML posts - mails are wrapped in a way such
that the text only takes up a third of my monitor. This is one of those
things where the more I notice it, the more it annoys me :/

[...]

I think that even for emails, the line length should be kept at a reasonable
value in order to maximize the readability. Such value is usually lower than
80, as shown, for example, in
https://baymard.com/blog/line-length-readability . I do have a large screen,
but I keep my email/text editors quite narrow in order to allow less than
100 characters per line. Of course YMMV.

Bye,
Giuseppe

[gregor herrmann]

Post by Giuseppe Sacco
I think that even for emails, the line length should be kept at a reasonable
value in order to maximize the readability. Such value is usually lower than
80, as shown, for example, in
https://baymard.com/blog/line-length-readability . I do have a large screen,
but I keep my email/text editors quite narrow in order to allow less than
100 characters per line. Of course YMMV.

Thank you for this link.
I've been thinking about describing my personal experiences for some
days but this web page explains it much better than I could have
written it myself:

Following long lines and than backtracking to the next line is
tedious for me; and if I have to turn my head right and left I'm much
more prone to just delete a mail than to follow through and complete
reading the whole text. -- There's a reason why texts in newspapers
are typically in columns and not across the whole page.

I acknowledge that there are people in Debian whose neck and eyes
are better than mine, and who have less knowledge about email
customs, and who use broken MUAs, and who want me to adjust my
terminal size but I'd like to note anyway that I'm not supporting any
change in the recommendations for Debian mailing lists, and I'll keep
ignoring unreadable emails in the future.

And I'd also like to thank people who pushed me into exploring
format=flowed in MUAs and editors further. I enjoy(ed) experimenting
with these things :)


Cheers,
gregor

[Jonas Smedegaard]

Quoting gregor herrmann (2025-03-07 00:14:19)

Post by gregor herrmann

Post by Giuseppe Sacco
I think that even for emails, the line length should be kept at a reasonable
value in order to maximize the readability. Such value is usually lower than
80, as shown, for example, in
https://baymard.com/blog/line-length-readability . I do have a large screen,
but I keep my email/text editors quite narrow in order to allow less than
100 characters per line. Of course YMMV.

Thank you for this link.

For completeness sake, I recommend to take newer research into account,
which a) questions if longer lines generally harms reading due to flaws
in especially one major research project from 2029, and b) points at
printed and digital texts affecting readability differently:
https://designregression.com/article/line-length-revisited-following-the-research

Despite long lines possibly not really *generally* hampering
readability, some of us *are* helped by following the typographic
conventions of 50-70 chars per line, be it due to e.g. dyslexia or
simply years of training our reading skills with print style texts.

Yes, some of us are younger, which quite likely means that reading
skills have been trained to a larger degree on online media than on
printed books, i.e. less commonly following typographic conventions
and therefore potentially more fluent in processing long lines.

SÞren proposes to simply not wrap when composing. That helps reading on
narrow width devices, but harms reading on conventional MUAs expecting
less than 80 chars per line, and harms reading on wide width devices for
some of us. Sure we can then tell folks to change MUA and to resize
their windows, but that is not nice to impose of human beings, being
creatures of habit.

I favor the proposal of continuing to follow the convention of wrapping
below 80 chars per line, and ecourage the use of f=f. That helps those
stock in the 90s, either mentally or through their choice of arcane MUA,
but harms those with large width MUAs and skilled reading long lines,
and those reading emails on narrow width devices. But only the
(allegedly large) subset of those users who use MUAs not supporting f=f.

Post by gregor herrmann
Following long lines and than backtracking to the next line is
tedious for me; and if I have to turn my head right and left I'm much
more prone to just delete a mail than to follow through and complete
reading the whole text. -- There's a reason why texts in newspapers
are typically in columns and not across the whole page.
I acknowledge that there are people in Debian whose neck and eyes
are better than mine, and who have less knowledge about email
customs, and who use broken MUAs, and who want me to adjust my
terminal size but I'd like to note anyway that I'm not supporting any
change in the recommendations for Debian mailing lists, and I'll keep
ignoring unreadable emails in the future.

Yes, arguably the issue of non-wrapped text causing too long lines is a
luxury problem that can be addressed by simply changing window size.
But that is asking creatures of habit to change habits, which is a lot.

Interestingly, I see this as a combined social and technical issue, and
since we are hackers, I favor that we try explore the option of hacking
our tools, before giving up and instead impose pressure on the habits of
our peers (because obviously *my* habits are a priority, it must be the
habits of others that need to change, right?).

Let us please continue to respect the ancient rules of email style,
and try explore format=flowed, which might be old too but evidently
not widely known prior to this thread!

- Jonas

[Soren Stoutner]

At this point in the discussion I would like to progress toward a decision.

One way to do so would be a GR. On one hand, using a GR to modify one line
of the code of conduct for the mailing list seems like a rather large hammer
for a rather small problem. But on the other hand, many people feel strongly
enough about this that a GR might be the only mechanism where people will
feel like the outcome is fair.

My question is, is there any other decision making process that would be
preferable to a GR to decide this issue?

[Holger Levsen]

Post by Soren Stoutner
My question is, is there any other decision making process that would be
preferable to a GR to decide this issue?

another outcome would be to leave things like they are. of course we could
have a GR to get to that result too.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

People complaining about Debian changing something, please queue to the left.
People complaining about Debian moving too slowly please queue to the right.
Thank you. (@ekuber)

[Philip Hands]

Post by Soren Stoutner
At this point in the discussion I would like to progress toward a decision.
One way to do so would be a GR. On one hand, using a GR to modify one line
of the code of conduct for the mailing list seems like a rather large hammer
for a rather small problem. But on the other hand, many people feel strongly
enough about this that a GR might be the only mechanism where people will
feel like the outcome is fair.
My question is, is there any other decision making process that would be
preferable to a GR to decide this issue?

You seem to be under the impression that there's an emerging consensus
in favour of your idea.

From my reading of this thread, the only real consensus seems to be that
format=flowed is a good idea (as a result of which I intend to persuade
my mail setup to generate that when I've got a moment).

I doubt that a GR is justified, especially if all it's going to end up
doing is adding a recommendation for format=flowed to the CoC that isn't
actually required for people to adopt the use of format=flowed.

Cheers, Phil.