~sircmpwn/public-inbox

5 2

useplaintext.email and format=flowed

Daniel Long Sockwell
Details
Message ID
<87wo85l3c5.fsf@codesections.com>
DKIM signature
pass
Download raw message
After rereading https://useplaintext.email, I have a couple of best-practice questions not addressed by the guide. 

First, what is the best way to wrap text between hard-wrapping and using format=flowed?  The site states: 

> senders of user-authored emails [should], hard-wrap [users] lines at 72 columns by inserting newlines at the nearest word boundary. Optionally, use format=flowed instead to allow plaintext emails to be displayed and composed without hard wrapping. 

Is one of these methods better than the others?  Additionally, if one does use format=flowed, what line length is best?  (In case anyone is unfamiliar with format=flowed, it is documented in its RFC: 
https://www.ietf.org/rfc/rfc2646.html)

As I see it, there are essentially three options:

1. Hard-wrap lines at 72 characters
   Pros:
     - Simple.
     - True to "plaintext" spirit.
   Cons:
     - Leads to "embarrassing line wrap"/combing when viewed on 
     screens with fewer than ~72 lines (especially bad on phones).

2. Use format=flowed with softwrap at 72 characters
   Pros:
     - Full backwards compatibility with hard-wrapping (it just
     adds whitespace).
     - Fixes combing problem when viewed on clients that
     implement format=flowed (e.g., Mutt, gnus).
     - Encourages clients to reflow text based on the users settings.
   Cons:
     - Does nothing to solve the combing problem on clients that don't
     implement format=flowed (which, to my knowledge, includes 
     basically all phone clients).

3. Use format=flowed without softwraping lines inside paragraphs
   Pros:
     - Avoids combing on all clients, leading to best plaintext
     experience for mobile email clients.
     - Identical experience for clients that implement format=flowed
     based on user settings.
   Cons:
     - Leads to excessively long lines for clients that don't
     implement format=flowed.  If the client has a small screen and
     wraps lines, this is not an issue.  But it is if the client has
     a large screen or uses a horizontal scroll bar.
     - Does not comply with the SHOULD recommendation to wrap lines 
       at 72 characters
     - Causes unwrapped lines in the raw email.


Based on all of the above, I am leaning towards solution three as a best practice (and that is how I have configured my client to send this email).  However, I would be interested in thoughts from the list, including feedback on how this email displays.  (From my own testing, it should display properly on Mutt and gnus, and does *not* display properly on mu4e with default settings.)  I first came across the idea of using format=flowed without internal softwrapping at https://vxlabs.com/2019/08/25/format-flowed-with-long-lines/. 

I would be especially interested in any negative experiences people have had with format=flowed.  FastMail argues that format=flowed breaks patches: https://fastmail.blog/2016/12/17/format-flowed/.  I am somewhat skeptical that this is an issue in practice, especially given the prevalence of tools like git-send-email.  But I am open to being corrected. 

One related, but distinct, question: What are best practices for character encoding? 

I have noticed that Quoted-Printable is increasingly common.  Does using it detract from the plaintext nature of the email?  It does make the source slightly less readable.  (Of course, there will be situations where it is clearly justified, such as when writing in a language that requires non-ASCII characters.  But I'm wondering about the situation I frequently am in where I don't *need* non-ASCII characters but might use the occasional em dash if given the chance.) 

If there is a consensus on any of the above, it might be worth adding a bit to the useplaintext.email guide.  I would be happy to submit a patch if that seems helpful. 

I look forward to hearing others' thoughts.

Best,
Daniel
Details
Message ID
<C0YTIIS1AUYB.18MSYKXNYAF3Z@homura>
In-Reply-To
<87wo85l3c5.fsf@codesections.com> (view parent)
DKIM signature
pass
Download raw message
Per the RFC, format=flowed emails should be wrapped at 72 characters,
for compatibility with clients which don't recognize it. Your email is
annoying to read for me because you have not configured it this way.
format=flowed with no line length limit is basically the same thing as
not using format=flowed at all.
Daniel Long Sockwell
Details
Message ID
<87v9npl21d.fsf@codesections.com>
In-Reply-To
<C0YTIIS1AUYB.18MSYKXNYAF3Z@homura> (view parent)
DKIM signature
pass
Download raw message
> Per the RFC, format=flowed emails should be wrapped at 72 characters, 
> for compatibility with clients which don't recognize it.

That is true, but the word "should" is doing a lot of work there.
Specifically, the RFC uses "SHOULD" rather than "MUST", meaning that it
is not a requirement.  But I definitely take your point that it's 
bending the RFC.

> Your email is annoying to read for me because you have not configured 
> it this way.

Fair enough, and good to know; I'm sending this email with a line length
of 72 characters.  If you don't mind the question, is this with Aerc?
I'll add it to the list of clients that don't reflow format=flowed
emails.  I notice that the lists.sr.ht public inbox also doesn't reflow
text, which is another point in favor of not relying on that behavior in 
clients.

> format=flowed with no line length limit is basically the same thing as 
> not using format=flowed at all.

I disagree.  It's just as bad as not using format=flowed for clients
that *don't* implement format=flowed reflowing.  But it is as good as
any other use of format=flowed (and better than hard-wrapping) for
clients that *do* implement format=flowed reflowing as suggested in the 
RFC.

For example, with Mutt (and default values for reflow_text and
reflow_wrap), the email I sent would be wrapped to 78 characters.  And
that value is user-defined and does not need to be lowered to allow room
for quoting - it is applied *after* quoting.  Together, that leads to a 
*better* experience than with hard-wrapped text.

On the other hand, I don't like relying on specific clients to render
the email correctly, especially if format=flowed reflowing support isn't 
as widespread as I would like.

I guess I need to weigh sending emails that look bad on clients that
don't support format=flowed reflowing against sending emails that look
bad on phones.  Or I suppose that I could decide which format to use on
a case-by-case basis, but that quickly gets complicated given that many
emails go to multiple people and even one person might view the same 
email in multiple clients.
Details
Message ID
<C0YUOHDLK3SC.3UEFZ7BYJT714@homura>
In-Reply-To
<87v9npl21d.fsf@codesections.com> (view parent)
DKIM signature
pass
Download raw message
On Sat Feb 29, 2020 at 12:46 PM, Daniel Long Sockwell wrote:
> Fair enough, and good to know; I'm sending this email with a line length
> of 72 characters. If you don't mind the question, is this with Aerc?
> I'll add it to the list of clients that don't reflow format=flowed
> emails. I notice that the lists.sr.ht public inbox also doesn't reflow
> text, which is another point in favor of not relying on that behavior in
> clients.

Aye, I'm using aerc. And indeed, lists.sr.ht does not support
format=flowed either. Wrapping at 72 columns allows for graceful
degredation for clients which don't support format=flowed. Your reply is
much easier to read :)

> I disagree. It's just as bad as not using format=flowed for clients
> that *don't* implement format=flowed reflowing. But it is as good as
> any other use of format=flowed (and better than hard-wrapping) for
> clients that *do* implement format=flowed reflowing as suggested in the
> RFC.

I disagree that it's better than hard wrapping. I don't have a problem
with hard wrapping at all, and it's better for compatibility with more
clients. Looks bad on phones < looks bad on my terminal, imo. My
terminal was here first.
Daniel Long Sockwell
Details
Message ID
<87sgitl05v.fsf@codesections.com>
In-Reply-To
<C0YUOHDLK3SC.3UEFZ7BYJT714@homura> (view parent)
DKIM signature
pass
Download raw message
Drew DeVault wrote:
> I don't have a problem with hard wrapping at all, and it's better for compatibility with more clients. Looks bad on phones < looks bad on my terminal, imo. My terminal was here first. 

Fair enough.  And, in general, I care more about looking good on a terminal than on a phone.  The problem is that there are a lot more phones out there than terminals - and so I only agree with your "more clients" statement if you're talking about the number of client implementations rather than the number of users. 

I guess the *real* solution is to stop emailing so many people who expect my emails to look decent on Gmail/Outlook on their Android and Apple phones.  But that's more of a long-term project and less of a config change!  Until then, trade offs remain.
Daniel Long Sockwell
Details
Message ID
<87r1ydkzyl.fsf@codesections.com>
In-Reply-To
<87sgitl05v.fsf@codesections.com> (view parent)
DKIM signature
pass
Download raw message
Er, apparently my config change did not persist, which goes to show the
perils of attempting to modify my format based on recipient.  Re-sending
with less obnoxious formatting.

Drew DeVault wrote:
> I don't have a problem with hard wrapping at all, and it's better for
> compatibility with more clients. Looks bad on phones < looks bad on my
> terminal, imo. My terminal was here first. 

Fair enough.  And, in general, I care more about looking good on a terminal than
on a phone.  The problem is that there are a lot more phones out there than
terminals - and so I only agree with your "more clients" statement if you're
talking about the number of client implementations rather than the number of
users. 

I guess the *real* solution is to stop emailing so many people who expect my
emails to look decent on Gmail/Outlook on their Android and Apple phones.  But
that's more of a long-term project and less of a config change!  Until then,
trade offs remain.