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 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 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.
The purpose of this email is to propose that the expectation thatI am opposed.
emails should be wrapped at 80 characters when they are sent should be dropped.
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.
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.
* Jeremy Stanley <fungi@yuggoth.org> [250226 13:39]:
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.
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.
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.
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.
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.
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.
Can we strongly recommend format=flowed instead?+1
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.
Hello,
On Thu, 27 Feb 2025, at 12:14, Vincent Lefevre wrote:
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 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 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.
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.
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.
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 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.
Le 27 février 2025 12:14:18 GMT+01:00, Vincent Lefevre <vincent@vinc17.net> a
See below how your message ends up being wrapped in my mobile client.
That's readable for some strange/low value of $readable.
Le 27 février 2025 12:14:18 GMT+01:00, Vincent Lefevre <vincent@vinc17.net> a
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.
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.
Given the above four points, I propose the line from the code of conduct quoted above be
changed to read:
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 wasbecause I had set KMail to wrap lines at 80 characters.
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 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.
On Thu Feb 27, 2025 at 1:29 PM GMT, Colin Watson wrote:
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.
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
On Wed, Feb 26, 2025 at 11:21:42AM -0700, Soren Stoutner wrote:
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 thread did, however, cause me to work out how to configure my mailer to send format=flowed,
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/
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
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?
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.
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/
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.”
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/
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 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 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.”
On Wed Feb 26, 2025 at 6:21 PM GMT, Soren Stoutner wrote:
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.
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.
On Feb 27, 2025 12:02, Blair Noctis <ncts@debian.org> wrote:
actually struggle to read the hard-wrapped-at-80-then-wrapped-again text.The standard for email is 74 chars, not 80...
On Thu Feb 27, 2025 at 4:48 PM GMT, Soren Stoutner wrote:
“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.
On Fri, Feb 28, 2025 at 06:30:00PM +0100, thomas@goirand.fr wrote:
On Feb 27, 2025 12:02, Blair Noctis <ncts@debian.org> wrote:
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
Format=flowed is being entirely driven by the belief that “We reallyI believe the idea is more like "We want the receiving MUA to do the
want the sending MUA to wrap text, but it creates horrible problems, so
here is a cludge to work around it.”
https://www.fastmail.com/blog/format-flowed/Only a webmail provider can bitch about the complexity of text wrapping
[off-list]
On Fri Feb 28, 2025 at 5:39 PM CET, Soren Stoutner wrote:
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
have "Content-Type: text/plain; charset=utf-8" instead of "Content-Type: 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 :)
* Soren Stoutner <soren@debian.org> [2025-02-28 10:53]:
Format=flowed is being entirely driven by the belief that “We reallyI believe the idea is more like "We want the receiving MUA to do the
want the sending MUA to wrap text, but it creates horrible problems, so >>here is a cludge to work around it.”
line wrapping, but we do not want to break MUAs which cannot do it
(yet)."
On Sat, 1 Mar 2025 09:48:36 +0100, Timo Röhling <roehling@debian.org>
wrote:
* Soren Stoutner <soren@debian.org> [2025-02-28 10:53]:
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.
¹ 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.
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).
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).
* Soren Stoutner <soren@debian.org> [2025-02-28 10:53]:
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)."
https://www.fastmail.com/blog/format-flowed/
Open source webmails also exist.
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?
Looks pretty awful to me. Screenshot attached.
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.
On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss
wrote:
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.
On 2025-03-03 18:39, Soren Stoutner wrote:
On Friday, February 28, 2025 7:30:53 PM MST Mason Loring Bliss
wrote:
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.
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.
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?
On 2025-03-03 10:35:32 -0700 (-0700), Soren Stoutner wrote:
[...]
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.
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!
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.
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.
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.
Am Montag, dem 03.03.2025 um 13:38 -0700 schrieb 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.
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.
On Monday, March 3, 2025 11:38:29 AM MST Philipp Kern wrote:
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.
Soren Stoutner <soren@debian.org> writes:
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.
However, I would appreciate it if this discussion were not hijacked
to discuss HTML vs. plain text.
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.
Soren Stoutner <soren@debian.org> writes:
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.
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.
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.
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.
Hence, I propose that we change the expectation so that the sending
MUA is not expected to wrap text.
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.
On Mon Mar 3, 2025 at 9:42 PM GMT, Soren Stoutner wrote:
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 am surprised nobody has mentionned support (or lack of support) of text/markdown at this point...[...]
On 2025-03-05 08:52:22 +0900 (+0900), Charles Plessy wrote:
[...]
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!
;)
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?
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?
On Tue Mar 4, 2025 at 7:52 PM GMT, Soren Stoutner wrote:[...]
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.
Given the above four points, I propose the line from the code of conduct quoted above be changed to read: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.
“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
Therefore, I feel the above wording is fair for everyone.
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
This (as a mild but easy to get example of pre-formatted text):
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
Hi all,
On 2025-02-26 10:21, Soren Stoutner wrote:
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?
Hi all,
On 2025-02-26 10:21, Soren Stoutner wrote:
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.
On Thu, 06 Mar 2025 14:53:07 +0100, Giuseppe Sacco wrote:
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.
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.
It is essential to have a method for distinguishing between hard and
soft newlines if you want to reflow text properly.
On Thu Mar 6, 2025 at 7:08 AM GMT, Henrik Ahlgren wrote:
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.
My question is, is there any other decision making process that would be preferable to a GR to decide this issue?
Otto Kekäläinen wrote:
I think this a reasonable suggestion by Soren. […]
Incidentally, the suggestion is good as illegible on a
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?
Soren Stoutner <soren@debian.org> writes:
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.
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:[...]
You seem to be under the impression that there's an emerging consensus
in favour of your idea.
Yes, I feel like there are a majority of Debian Developers who are in favor of making the
change that I propose, partially based on the number of people who have commented
only once in the conversation with a short message in favor of the change. I also see a
small number of Debian Developers who are strongly opposed to the change.
I think those who are against the change feel much more strongly about their position
than those who are for the change, but my sense is that if it goes to a GR vote the change
will pass.
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.
Soren Stoutner <soren@debian.org> writes:
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:
You seem to be under the impression that there's an emerging
consensus in favour of your idea.
Yes, I feel like there are a majority of Debian Developers who are
in favor of making the change that I propose, partially based on
the number of people who have commented only once in the
conversation with a short message in favor of the change.
OK, so that provoked me to check if it's my input filter that's
defective, or yours.
Having skimmed through the 106 mails I currently see in this thread,
this is the way I'd summarise people's preferences (if anyone sees
that I've mis-characterised their view, I promise it was not
intentional, so please forgive me and correct my mistake)
* Against the proposal
The Wanderer
Soren Stoutner <soren@debian.org> writes:
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:
Soren Stoutner <soren@debian.org> writes:
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.
Yes, I feel like there are a majority of Debian Developers who are
in favor of making the change that I propose, partially based on the number of people who have commented only once in the conversation
with a short message in favor of the change.
OK, so that provoked me to check if it's my input filter that's
defective, or yours.
Having skimmed through the 106 mails I currently see in this thread,
this is the way I'd summarise people's preferences (if anyone sees
that I've mis-characterised their view, I promise it was not
intentional, so please forgive me and correct my mistake)
* Unclear…
Jonathan McDowell
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:
Soren Stoutner <soren@debian.org> writes:
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.
Yes, I feel like there are a majority of Debian Developers who are in favor of making the
change that I propose, partially based on the number of people who have commented
only once in the conversation with a short message in favor of the change.
Soren Stoutner <soren@debian.org> writes:
On Saturday, March 8, 2025 4:23:56 PM MST Philip Hands wrote:
Soren Stoutner <soren@debian.org> writes:
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.
Yes, I feel like there are a majority of Debian Developers who are in favor of making the
change that I propose, partially based on the number of people who have commented
only once in the conversation with a short message in favor of the change.
OK, so that provoked me to check if it's my input filter that's
defective, or yours.
Having skimmed through the 106 mails I currently see in this thread,
this is the way I'd summarise people's preferences (if anyone sees that
I've mis-characterised their view, I promise it was not intentional, so please forgive me and correct my mistake)
* Supporting the proposal
Soren Stoutner
Andrej Shadura
Blair Noctis (as well as supporting format=flowed,
or perhaps just anti-thunderbird)
Tino Didriksen (or perhaps format=flowed)
Otto Kekäläinen (or perhaps supporting Charles Plessy)
* Against the proposal
Jeremy Stanley
Marco d'Itri
Bastian Blank
Jeremy Sowden
The Wanderer
Giuseppe Sacco
gregor herrmann (while suporting format=flowed)
Andreas Metzler
* Advocating Format=flowed
Andrea Pappacoda
Jonathan Dowland
Timo Röhling
Aurélien COUDERC
Colin Watson
Aaron Rainbolt
Jeremy Stanley
Wookey
Philipp Kern
Roger Lynn (somewhat)
Jonas Smedegaard
Philip Hands
Julien Plissonneau Duquène
* Unclear
Marvin Renich
Vincent Lefevre (seems against though)
Thomas Goirand
Jonathan McDowell
Marc Haber (but perhaps against everything ;-) )
Stephan Verbücheln
Holger Levsen (with strong hints of against)
Aaron Schrab
Bjørn Mork
Charles Plessy (suggesting complaints should be off-list)
Mario Limonciello (hints of format=flowed support)
Leandro Cunha
Thorsten Glaser (seems against though)
IOhannes m zmölnig (perhaps a supporter)
Stephan Verbücheln (against? at least against mixed HTML)
Henrik Ahlgren
Russ Allbery
James Lu
Andrey Rakhmatullin
I would sumarise that as follows:
In favour: 5 (including yourself)
+2 (possibly)
Against: 8
+5 (possibly)
for Format=Flowed: 13
Of the 13 F=F folk, several also lean against the proposal to some extent.
I may be over-counting your supporters (given the notes by them).
Perhaps I'm neglecting to count some of the pro-F=F folk as also being
in support of you, because I mis-read their mails or some such.
Regardless, it seems clear that you are suffering from confirmation bias.
It would be nice if you could take that into account to some extent.
Having skimmed through the 106 mails I currently see in this thread,
this is the way I'd summarise people's preferences (if anyone sees that
I've mis-characterised their view, I promise it was not intentional, so please forgive me and correct my mistake)
To be fair, while I *am* against the proposal, I'm also not a Debian Developer - just an interested observer of, and occasional participant
in, discussions on Debian mailing lists (including this one).
That's IMO something much more interesting than text/html that should
be implemented in MUAs (falling back to displaying it as text/plain >eventually) but for now it doesn't display at all in some e.g. in
Roundcube 1.6.10 that my service provider is using. An old version of >Thunderbird displays it at text/plain.
Of the 13 F=F folk, several also lean against the proposal to someJust for the record, you may count me amongst them, too.
extent.
Stephan Verbücheln (against? at least against mixed HTML)
I am also exploring the use of `text/markdown` as the default
content type for my emails.
My groff/troff reply to your earlier suggestion of this was only
somewhat tongue-in-cheek. Markdown isn't a singular clearly-specified syntax, but a family of them with several popular flavors in
widespread use (as Timo's parser option challenges indicate).
Bar said:
Baz said:You're both wrong
You're wrongNo you're wrong
<snip>
Mario Limonciello (hints of format=flowed support)
Thanks for the summary. I am of the camp of f=f.
At least with the MUA I'm using most of the time (Thunderbird) this is
the default, and no one has complained to me directly about it for any
email sent to the Kernel community or Debian community.
As it seems to be a polarizing discussion I do wonder if maybe it would
make most sense to have a "proper" vote to determine which way the
"silent majority" of developers actually lean?
I am planning on proposing a GR, but I want to take the time to make
sure I word it well. I expect to be able to do so in the next few
days.
Interesting. I guess that text could be interpreted as “Do not send
an HTML part, even if you also send a plain text part.”
Please don't send your messages in HTML; use plain text instead.https://www.debian.org/MailingLists/index.html
However, I would appreciate it if this discussion were not hijacked
to discuss HTML vs. plain text.
On Fri, Mar 14, 2025 at 02:49:26PM -0700, Soren Stoutner wrote:
On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario >Limonciello>
wrote:
<snip>
Mario Limonciello (hints of format=flowed support)
Thanks for the summary. I am of the camp of f=f.
At least with the MUA I'm using most of the time (Thunderbird) this is
the default, and no one has complained to me directly about it for any
email sent to the Kernel community or Debian community.
As it seems to be a polarizing discussion I do wonder if maybe it would
make most sense to have a "proper" vote to determine which way the
"silent majority" of developers actually lean?
I am planning on proposing a GR, but I want to take the time to make sure I >word it well. I expect to be able to do so in the next few days.
Please don't. Mobilizing the entire project to discuss and vote on the
exact format for sending plain text email is ridiculous. That silent
majority is silent, because, well, this issue is completely irrelevant.
On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario Limonciello
wrote:
<snip>
Mario Limonciello (hints of format=flowed support)
Thanks for the summary. I am of the camp of f=f.
At least with the MUA I'm using most of the time (Thunderbird) this is
the default, and no one has complained to me directly about it for any
email sent to the Kernel community or Debian community.
As it seems to be a polarizing discussion I do wonder if maybe it would
make most sense to have a "proper" vote to determine which way the
"silent majority" of developers actually lean?
I am planning on proposing a GR, but I want to take the time to make sure I word it well. I
expect to be able to do so in the next few days.
Am Montag, dem 03.03.2025 um 14:42 -0700 schrieb Soren Stoutner:
Interesting. I guess that text could be interpreted as “Do not send
an HTML part, even if you also send a plain text part.”
Are you serious? That does not make any sense.
Please don't send your messages in HTML; use plain text instead.
https://www.debian.org/MailingLists/index.html
How could it be more clear?
However, I would appreciate it if this discussion were not hijacked
to discuss HTML vs. plain text.
The whole discussion requires that we know what the rules mean,
especially if you want to change them.
Regards
On Fri Mar 14, 2025 at 9:49 PM GMT, Soren Stoutner wrote:
I am planning on proposing a GR, but I want to take the time to make
sure I word it well. I expect to be able to do so in the next few
days.
Short of a GR, you could determine who "owns" the CoC at the moment:
it's not clearly a Debian document like the DFSG, policy, etc.; in fact
it's probably the domain of the listmasters. Have you talked to them at
all?
It’s important enough to me.
On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio Terceiro wrote:
Please don't. Mobilizing the entire project to discuss and vote on
the exact format for sending plain text email is ridiculous. That
silent majority is silent, because, well, this issue is completely
irrelevant.
It’s important enough to me.
Because the primary interaction that most people have with
Debian is through email, changing the way that interaction works
is a big enough issue that I don’t see any other appropriate way
of making it outside of a GR.
On Wednesday, March 12, 2025 5:38:40 PM Mountain Standard Time Mario Limonciello
wrote:
<snip>
Mario Limonciello (hints of format=flowed support)
Thanks for the summary. I am of the camp of f=f.
At least with the MUA I'm using most of the time (Thunderbird) this is
the default, and no one has complained to me directly about it for any email sent to the Kernel community or Debian community.
As it seems to be a polarizing discussion I do wonder if maybe it would make most sense to have a "proper" vote to determine which way the
"silent majority" of developers actually lean?
I am planning on proposing a GR, but I want to take the time to make sure I word it well. I expect to be able to do so in the next few days.
Hi Soren,
On Sat Mar 15, 2025 at 3:47 PM CET, Soren Stoutner wrote:
On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio
Terceiro wrote:
Please don't. Mobilizing the entire project to discuss and vote on
the exact format for sending plain text email is ridiculous. That
silent majority is silent, because, well, this issue is completely
irrelevant.
It’s important enough to me.
I understand how you feel, but please keep in mind that changing the
current recommendation would degrade the experience for many people.
New recommendations, to me, should be net improvements. We've already discussed about a message format which solves your reflowing concerns,
while not degrading the experience where hard-wrapped text is fine.
Moreover, as Antonio said, do you really think that this matter is
important enough to have everyone in Debian care about it?
Rather than trying to force my opinion on everyone, I'd work to improve existing software.
I thought about doing that, but those who are against this change feel so strongly about
their position I don’t think they would accept a change made that way as valid. In
addition, such a change doesn’t just need to apply to the mailing lists, but also to other
interactions with Debian by email, like the BTS. Because the primary interaction that most
people have with Debian is through email, changing the way that interaction works is a
big enough issue that I don’t see any other appropriate way of making it outside of a GR.
On Saturday, March 15, 2025 7:41:02 AM Mountain Standard Time Antonio Terceiro wrote:
Please don't. Mobilizing the entire project to discuss and vote on the
exact format for sending plain text email is ridiculous. That silent
majority is silent, because, well, this issue is completely irrelevant.
It’s important enough to me.
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.
[…]
such as:
# On time+3, Carol wrote:
# >On time+2, Bob wrote:
# >>On time+1, Alice wrote:
# >>>Some long reply line that supposedly gets wrapper at 7x chars or
# >>>so, continued.
# >>Some long reply line that supposedly gets wrapper at 7x chars or so,
# >>continued.
# >Some long reply line that supposedly gets wrapper at 7x chars or so,
# >continued.
# Some long reply line that supposedly gets wrapper at 7x chars or so,
# continued.
Which I find to be very annoying and hard to read from my editor (vim).
And checking how this is shown now in mutt (before sending), with
text_flowed disabled, but reflow_text enabled, indicates to me the
mangling is worse than I thought, but perhaps it's just reflow_text being applied to a text that is not yet sent and will not be format=flowed,
thus should not really be applied to, otherwise you might need to check
the raw text of the mail. :/
With every email you write more about this non topic to obviously most
of the longer time DDs you disqualifies yourself more in my eyes.
However, this GR is not flawed because Soren is a "new DD". That has
nothing to do with this and -- with so much respect and affection for
all of you -- I think that attitude fucking sucks. Soren has every right
to suggest this GR. I just disagree it's a good idea for the project and
how we get work done. There is **no** reason a DD who got their account
5 minutes prior can't suggest a GR if they know what they're doing.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 491 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 92:58:10 |
| Calls: | 9,679 |
| Files: | 13,723 |
| Messages: | 6,174,093 |