Re: Is linewrap dead? Now: Self hosted SMTP

[John Hawkinson]

(Replying to Mihai, but keeping Bastian's subject-line change...an operation 
which Mutt is not great at, but better than most...I dunno what to do with 
In-Reply-To/References: here, tho.)

Mihai Lazarescu  wrote on Mon, 12 Sep 2022
at 15:07:37 EDT in :

> It took some work to set it up, but that's it. Surely not a mass solution, 
> yet feasible and stable.
...
> Only Microsoft (outlook.com, hotmail.com) seem to filter the whole IP block, 
> but I am too lazy to ask the
> provider to fix or change provider altogether.

This is hard to take seriously. Precise numbers are hard come to by, but I 
think Microsoft is the number 2 hosting provider, globally, after Google/Gmail, 
and has a substantial market share. Deciding that it's OK to not worry about 
them suggests a very different attitude toward email reliability and 
interoperability than most people would choose.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Rand Pritelrohm]

On Mon, 12 Sep 2022 15:15:55 +
Nacho via Mutt-users  wrote:

>> What you describe is becoming more and more history, which I regret.
>> Let me give you the link of an article that should interest you.
>>
>> https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html
>>
>
>I don't agree with that article, it has some technical errors I will
>not discuss here because of lack of time and it being off topic.
>
>But in short, today it's just a matter of money and time to have your
>own email system working perfectly, of course the cost have increased
>wildly in the last few years and will keep doing so, but at least for
>me makes all the sense to pay for it.
>
>You can even give email accounts to people you want to comunicate
>with. many are more than happy to have a nice alternative to their
>gmail/hotmail/yahoo accounts.
>


Thank your for your feedback.

Rand.

Re: Is linewrap dead?

[Nacho via Mutt-users]

> What you describe is becoming more and more history, which I regret.
> Let me give you the link of an article that should interest you.
> 
> https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html

I don't agree with that article, it has some technical errors I will not discuss
here because of lack of time and it being off topic.

But in short, today it's just a matter of money and time to have your own
email system working perfectly, of course the cost have increased wildly in the
last few years and will keep doing so, but at least for me makes all the sense
to pay for it.

You can even give email accounts to people you want to comunicate with. many are
more than happy to have a nice alternative to their gmail/hotmail/yahoo 
accounts.

Re: Is linewrap dead?

[Rand Pritelrohm]

On Sun, 4 Sep 2022 12:34:11 +
Nacho via Mutt-users  wrote:

[...]
>
>Apart from that, the big difference between using whatsapp or email is
>that with email you get independence: I have my own email servers
>using my own domains that just a court can take away from me, use the
>OS and MTA of my choice that I can modify and compile from source, set
>up my spam filters, webmail and everything else just the way I want,
>and everything works the way I want.
>
>It's like being the owner of my own piece of land or just a poor
>peasant in somebody's else huge land.
>
>
[...]

What you describe is becoming more and more history, which I regret.
Let me give you the link of an article that should interest you.

https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html

Rand.

Re: Is linewrap dead?

[Martin Trautmann]

On 22-09-07 01:00, raf via Mutt-users wrote:

On Mon, Sep 05, 2022 at 10:45:09PM -0400, Kurt Hackenberg  >  wrote: 
> > > I expect it is done in mutt because it

must be done (for transport), > and it would be a mistake to assume that
it will be done by the > editor, whatever editor it is. I don't think
that mutt makes any > assumptions about which editor is used.
An editor is required for replies only - which can be configured to use
format=flowed.

But most of the time you read only. Then you do not need an editor,
which is much more powerful.


But I think the real problem with format=flowed, and possibly the  > reason why 
the large corporate web-based mail providers don't

support > it is that it's not sufficiently trivial to make it happen.
I feel most of f=f is pretty straight foward. In fact, translating plain
text to html appears to be more complicated that flowed to html, while
html to html is the most complicated task, when you filter out bogus
code and want to apply the local styles.

Re: Is linewrap dead?

[raf via Mutt-users]

On Mon, Sep 05, 2022 at 10:45:09PM -0400, Kurt Hackenberg  
wrote:

> On Tue, Sep 06, 2022 at 08:54:58AM +1000, Cameron Simpson wrote:
> 
> > I'm not sure we're disagreeing here, except for the conceptual
> > separation of the space-stuffing step.
> 
> I agree that it's a separate step, or layer. I just think it might better be
> done within the editor -- or special-purpose program, or script that runs
> two programs -- rather than be done later by Mutt itself. That is, Mutt
> could farm out the whole job, rather than have the external program do half
> and Mutt do half.
> 
> I would guess that it's split just because it was made for vim, and vim
> can't do the space-stuffing. I don't know the history, though.

I expect it is done in mutt because it must be done
(for transport), and it would be a mistake to assume
that it will be done by the editor, whatever editor it
is. I don't think that mutt makes any assumptions about
which editor is used.

Also, vim could do it. Vim can do anything to text, and
it can be automated, but of course, it needs to
configured to do so. Not necessarily with formatoptions
settings, but perhaps with filetype-based autocommands.

But I think the real problem with format=flowed, and
possibly the reason why the large corporate web-based
mail providers don't support it is that it's not
sufficiently trivial to make it happen. So maybe it
just isn't used by enough people. It seems that vim
makes it fairly easy, but that's just one editor.
Although the real reason might just be a preference
for html email.

cheers,
raf

Re: Is linewrap dead?

[Kurt Hackenberg]

On Mon, Sep 05, 2022 at 10:53:15PM -0400, Kurt Hackenberg wrote:


Here's an updated version of my Emacs mode for Mutt flowed text...


Here's a picture of it in use, with long lines being word-wrapped by 
Emacs's visual-line-mode.

Re: Is linewrap dead?

[Kurt Hackenberg]

Here's an updated version of my Emacs mode for Mutt flowed text, with 
tweaks: displays quoted text in a different color, handles signature 
separator lines correctly, has a little more documentation.
(defvar mutt-flowed-text-mode-map
  (let ((map (make-sparse-keymap)))
(set-keymap-parent map text-mode-map)
(define-key map "\C-cd" 'flowed-text-decode-region)
(define-key map "\C-ce" 'flowed-text-encode-region)
(define-key map "\C-cD" 'flowed-text-decode-buffer)
(define-key map "\C-cE" 'flowed-text-encode-buffer)
(define-key map "\C-c\C-c" 'flowed-text-done)
map)
  "Keymap for Mutt flowed text mode.")

(define-derived-mode mutt-flowed-text-mode text-mode "Mutt flowed text"
  "Major mode to compose text/plain format=flowed for mail reader Mutt.

Type and edit text with each paragraph being a single long line.
When you're done, use a mode command to encode it as flowed text;
that will insert soft line breaks.  You can decode it (go back to
one-line paragraphs) and encode it any time, but make sure the
message body is encoded when you exit Emacs and hand the message
back to Mutt.

You can use visual-line-mode to display those long lines
nicely.  Also, you might want to make trailing whitespace visible
by setting the variable show-trailing-whitespace, or by using
whitespace-mode.

Encoding and decoding work on both quoted and unquoted text.

This mode sets the buffer-local variable fill-column to a very
large number, because normally Emacs text fill would damage both
single-line paragraphs and text encoded as format=flowed.  With
that large number, you could use the Emacs fill functions to turn
a multi-line paragraph into a single-line paragraph.

Don't encode/decode the message header section; that could break
things.  Trailing spaces are not unusual in headers, and long
lines are possible.  It's best to tell Mutt

set edit_headers = no

to avoid that possibility.

This mode assumes DelSp=no (the default), because that's what
Mutt generates.

This mode does not space-stuff the message, because Mutt does that.
For that reason, this may not be usable with other mail readers."

  :syntax-table=nil :abbrev-table=nil

  (setq-local delsp nil);buffer-local

  (defface flowed-text-quoted-text '((t . (:foreground "SlateBlue"))) "")
  (setq flowed-text-font-lock-keywords '(("^>+.*$" . flowed-text-quoted-text)))
  (setq ft-yet-more-indirection 'flowed-text-quoted-text)
  (setq flowed-text-font-lock-keywords '(("^>+.*$" . ft-yet-more-indirection)))
  (setq font-lock-defaults '(flowed-text-font-lock-keywords t)) ;buffer-local

  (setq fill-column most-positive-fixnum)) ;buffer-local

(defun flowed-text-quote-level ()
  (save-excursion
(forward-line 0)
(looking-at ">*")
(length (match-string-no-properties 0

(defun ft-looking-at-flowed-line-p ()
  (and
   (looking-at-p ".* \n")
   ;;not signature separator (which can be quoted, can be space-stuffed)
   (not (looking-at-p ">* ?-- \n"

(defun flowed-text-decode-region (begin end)
  "Decode text/plain format=flowed.  That is, remove its soft line
breaks.  This turns a flowed paragraph into a single-line paragraph.
Works on both quoted and unquoted text."
  (interactive "r")
  (save-excursion
(let (quote-level endm)
  (setq endm (set-marker (make-marker) end))
  (set-marker-insertion-type endm t)
  (goto-char begin)
  (while (< (point) endm)
(setq quote-level (flowed-text-quote-level))
(if (ft-looking-at-flowed-line-p)
(progn
  (forward-line)
  (if (and (< (point) endm)
   (equal (flowed-text-quote-level) quote-level))
  (progn
(delete-char (if delsp -2 -1))
(delete-char quote-level))
(progn ;else: invalid space, remove it
  (backward-char 1)
  (delete-char -1)
  (forward-char
  (forward-line))

(defun flowed-text-encode-region (begin end)
  "Encode text into text/plain format=flowed: insert soft line
breaks into lines longer than 78 characters.  Works on both
quoted and unquoted text."
  (interactive "r")
  (save-excursion
(let (maxlen endm bl el quote-level)
  (setq maxlen (if delsp 77 78))
  (setq endm (set-marker (make-marker) end))
  (set-marker-insertion-type endm t)
  (goto-char begin)
  (while (< (point) endm)
;;line-end-position stays within a field, forward-line doesn't
(setq bl (point))   ;beginning of line
(setq el (line-end-position))   ;end of line
(setq quote-level (flowed-text-quote-level))
;;If a line is a single very long word -- no spaces -- we
;;can't break it with DelSp=no, so leave it alone.  I hope
;;Mutt will use quoted-printable to insert soft line breaks at
;;that level, at least if the line is longer than 998
;;characters.
;;
 

Re: Is linewrap dead?

[Kurt Hackenberg]

On Tue, Sep 06, 2022 at 08:54:58AM +1000, Cameron Simpson wrote:

I'm not sure we're disagreeing here, except for the conceptual 
separation of the space-stuffing step.


I agree that it's a separate step, or layer. I just think it might 
better be done within the editor -- or special-purpose program, or 
script that runs two programs -- rather than be done later by Mutt 
itself. That is, Mutt could farm out the whole job, rather than have 
the external program do half and Mutt do half.


I would guess that it's split just because it was made for vim, and vim 
can't do the space-stuffing. I don't know the history, though.

Re: Is linewrap dead?

[Cameron Simpson]

On 05Sep2022 12:56, Kurt Hackenberg  wrote:

On Mon, Sep 05, 2022 at 07:40:54PM +1000, Cameron Simpson wrote:
It seems a little conceptually cleaner to have the editor do the 
whole job, rather than divide it between the editor and Mutt. But 
another complication is that you can edit a message more than once...


I think space stuffing is effectively an escape mechanism, like 
quoted printable; not something you see at authoring time. The RFC 
even says "(Note that space-stuffing is conceptually similar to 
dot-stuffing as specified in [SMTP].)", which is again a transport 
level escaping.


So we need the overt trailing-space stuff because that's an 
indicator of end-of-paragraph in f=f, but not the space stuffing, 
because that is only needed to transport the text.


Space-stuffing doesn't have to be shown to the user while editing, but 
it's part of format=flowed, and it's required, not optional. The 
paragraph before the one you quoted is this:


   On generation, any unquoted lines which start with ">", and any lines
   which start with a space or "From " MUST be space-stuffed.  Other
   lines MAY be space-stuffed as desired.




Yes, it is required, just as dot stuffing in SMTP is required. I still 
consider it part of the transport/encoding layer _conceptually_. A bit 
like I can compose some nonASCII Unicode text and require 
quoted-printable UTF-8 behind the scenes I suppose.


That's why I consider it conceptually separate. I'm not arguing that 
there's no requirement for space stuffing. I'm arguing that there's no 
need or benefit to burden the authoring interface with it.


A bit like your long-lines<->format=flowed mode switch in your emacs 
mode: they're semanticly equivalent, but you could compose in long-lines 
mode and _send_ in format=flowed format as an entirely valid way to 
author a format=flowed message.


I'm not sure we're disagreeing here, except for the conceptual 
separation of the space-stuffing step.


Cheers,
Cameron Simpson 

Re: Is linewrap dead?

[Kurt Hackenberg]

On Mon, Sep 05, 2022 at 07:40:54PM +1000, Cameron Simpson wrote:

It seems a little conceptually cleaner to have the editor do the 
whole job, rather than divide it between the editor and Mutt. But 
another complication is that you can edit a message more than once...


I think space stuffing is effectively an escape mechanism, like quoted 
printable; not something you see at authoring time. The RFC even says 
"(Note that space-stuffing is conceptually similar to dot-stuffing as 
specified in [SMTP].)", which is again a transport level escaping.


So we need the overt trailing-space stuff because that's an indicator 
of end-of-paragraph in f=f, but not the space stuffing, because that 
is only needed to transport the text.


Space-stuffing doesn't have to be shown to the user while editing, but 
it's part of format=flowed, and it's required, not optional. The 
paragraph before the one you quoted is this:


On generation, any unquoted lines which start with ">", and any lines
which start with a space or "From " MUST be space-stuffed.  Other
lines MAY be space-stuffed as desired.

Re: Is linewrap dead?

[Cameron Simpson]

On 05Sep2022 01:52, Kurt Hackenberg  wrote:

On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote:

But not space-stuffing, right?
Aye. I avoid lines commencing with a ">" just because they look quoted 
to my eye anyway, so that aside "live" space stuffing in authoring is 
something I'd find distracting.


Agreed, I wouldn't want space-stuffing maintained on the fly, while 
editing. It could be done at the end, when handing the message back to 
Mutt.


It seems a little conceptually cleaner to have the editor do the whole 
job, rather than divide it between the editor and Mutt. But another 
complication is that you can edit a message more than once...


I think space stuffing is effectively an escape mechanism, like quoted 
printable; not something you see at authoring time. The RFC even says 
"(Note that space-stuffing is conceptually similar to dot-stuffing as 
specified in [SMTP].)", which is again a transport level escaping.


So we need the overt trailing-space stuff because that's an indicator of 
end-of-paragraph in f=f, but not the space stuffing, because that is 
only needed to transport the text.


[...]
The second one works differently. It's a "major mode"; it has commands 
to convert both ways between format=flowed and one-line paragraphs, 
while you edit. The idea is to type with each paragraph being a single 
long line, and then "encode" that as format=flowed when you're done.  
That doesn't mess with existing mechanisms, and doesn't take much code. 
Emacs has something called "visual line mode" to make those long lines 
not ugly.


Ah, I was wondering about that, because I find the one-line-paragraph 
thing wearing with quite long lines.


That second one is attached, for anyone who's interested (Cameron, I 
suppose you probably don't use Emacs).


Indeed not. I took the Other Path long ago.


Don't encode/decode the message header section; that could
possibly break things.  It's best to tell Mutt

   set edit_headers = no

to avoid that possibility.


I like to edit headers, so my vim-flavoured mode trims all trailing 
spaces from the header lines at startup:


1,/^$/s/  *$//

That way they're "hard newlines" from the flowed point of view, and 
survive.


Cheers,
Cameron Simpson 

Re: Is linewrap dead?

[Kurt Hackenberg]

On 2022/09/04 18:45, raf via Mutt-users wrote:


Hmm. I do "From-munging" on arrival.
I should probably read rfc3676 properly. :-)


Format=flowed includes a thing to protect the message from being damaged 
in the future by being written into an mbox file.

Re: Is linewrap dead?

[Kurt Hackenberg]

On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote:


But not space-stuffing, right?


I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to 
refresh my brain. Yeah, I don't think I'd want that when writing a message.


Which I guess is why Mutt space-stuffs the format=flowed that it 
gets back from the editor.


Aye. I avoid lines commencing with a ">" just because they look quoted 
to my eye anyway, so that aside "live" space stuffing in authoring is 
something I'd find distracting.


Agreed, I wouldn't want space-stuffing maintained on the fly, while 
editing. It could be done at the end, when handing the message back to Mutt.


It seems a little conceptually cleaner to have the editor do the whole 
job, rather than divide it between the editor and Mutt. But another 
complication is that you can edit a message more than once...


I've just written something for Emacs, to use Emacs to compose 
format=flowed for Mutt. Well, I wrote two things, that do it two 
different ways.


The first one does it like vim, maintaining format=flowed on the fly as 
you type, by adding things to the existing "fill" functions (re-wrap). 
I have it working -- I've used it to post a couple things here -- but I 
had to put fingers into existing Emacs mechanisms (by adding "advice" 
to functions), which I'm leery of, and I don't think it can be done in 
a buffer-local way.


The second one works differently. It's a "major mode"; it has commands 
to convert both ways between format=flowed and one-line paragraphs, 
while you edit. The idea is to type with each paragraph being a single 
long line, and then "encode" that as format=flowed when you're done. 
That doesn't mess with existing mechanisms, and doesn't take much code. 
Emacs has something called "visual line mode" to make those long lines 
not ugly. I just got it working...I've tested it, but not 
extensively...I'm using it for this message...


That second one is attached, for anyone who's interested (Cameron, I 
suppose you probably don't use Emacs).


Set it up like this in .muttrc:

set text_flowed = yes   #compose text/plain format=flowed
set editor = 'emacs --load=$HOME/elisp/mutt-flowed-text-mode.el %s 
--funcall=mutt-flowed-text-mode'
set edit_headers = no   #don't want to flow the header section

Fire up Mutt, compose a message, and type C-h m to get help on the Emacs mode.
(defvar mutt-flowed-text-mode-map
  (let ((map (make-sparse-keymap)))
(set-keymap-parent map text-mode-map)
(define-key map "\C-cd" 'flowed-text-decode-region)
(define-key map "\C-ce" 'flowed-text-encode-region)
(define-key map "\C-cD" 'flowed-text-decode-buffer)
(define-key map "\C-cE" 'flowed-text-encode-buffer)
(define-key map "\C-c\C-c" 'flowed-text-done)
map)
  "Keymap for Mutt flowed text mode.")

(define-derived-mode mutt-flowed-text-mode text-mode "Mutt flowed text"
  "Major mode to compose text/plain format=flowed for mail reader Mutt.

Type and edit text with each paragraph being a single long line.
When you're done, use a mode command to encode it as flowed text;
that will insert soft line breaks.  You can decode it (go back to
one-line paragraphs) and encode it any time, but make sure the
message body is encoded when you exit Emacs and hand the message
back to Mutt.

You could use visual-line-mode to display those long lines
nicely.  Also, you might want to make trailing whitespace visible
by setting the variable show-trailing-whitespace, or by using
whitespace-mode.

This mode sets the buffer-local variable fill-column to a very
large number, because Emacs text fill would damage both
single-line paragraphs and text encoded as format=flowed.

Don't encode/decode the message header section; that could
possibly break things.  It's best to tell Mutt

set edit_headers = no

to avoid that possibility.

This mode does not space-stuff the message, because Mutt does that.
For that reason, it may not be usable with other mail readers."

  :syntax-table=nil :abbrev-table=nil
  (setq-local delsp nil)
  (setq fill-column most-positive-fixnum))

(defun flowed-text-quote-level ()
  (save-excursion
(forward-line 0)
(looking-at ">*")
(length (match-string-no-properties 0

(defun flowed-text-decode-region (begin end)
  (interactive "r")
  (save-excursion
(let (quote-level endm)
  (setq endm (set-marker (make-marker) end))
  (set-marker-insertion-type endm t)
  (goto-char begin)
  (while (< (point) endm)
(setq quote-level (flowed-text-quote-level))
(if (looking-at-p ".* \n")
(progn
  (forward-line)
  (if (and (< (point) endm)
   (equal (flowed-text-quote-level) quote-level))
  (progn
(delete-char (if delsp -2 -1))
(delete-char quote-level))
(progn  ;else: invalid space, remove it
  (backward-char 1)
  

Re: Is linewrap dead?

[Cameron Simpson]

On 05Sep2022 08:37, raf via Mutt-users  wrote:

> I like your indenting of code blocks, but it seems to
> put an additional blank line after each code block.
> That might not be intentional.

Not intentional. I just wanted to keep the 4 space indent used to trigger a
code block for the same visual effect, since I use that instead of the
triple backticks usually. Pandoc tosses those spaces.


That's correct behaviour for markdown.


Doesn't mean I like it :-)


If you want the
output to be indented four spaces, the markdown source
needs to be indented eight spaces. But for email use,
it's a nice idea to do what you're doing.


I'd like the HTML to resemble the source MarkDown, visually.


If you want to prevent the extra line, the sed command
can be changed to remove theindenyt before the closing
line of the code block:

 sed '
 s/^\(\)\(.*<\/code><\/pre>\)$/\1\2/
 t post_pre_code
 /^/,/<\/code><\/pre>$/{
 s/^//
 s/^\(\)/\1/
 s/^\(<\/code><\/pre>\)/\1/
 }
 :post_pre_code
 '


Ah, right. Thanks.

Cheers,
Cameron Simpson 

Re: Re: Is linewrap dead?

[raf via Mutt-users]

On Sun, Sep 04, 2022 at 05:39:05PM +0200, Jan Eden via Mutt-users 
 wrote:

> On 2022-09-04 20:37, Cameron Simpson wrote:
> > On 04Sep2022 15:34, raf via Mutt-users  wrote:
> > > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson 
> > >  wrote:
> 
> > > > The `md2html` script is my personal script, which wraps `pandoc`
> > > > and post munges the HTML to indent the code blocks, which
> > > > `pandoc`'s HTML does not please my eye. It's here:
> > > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if
> > > > anyone wants a starting point.
> > > 
> > > Thanks, Cameron. It's odd that there isn't an md2html program out
> > > there already. I had to create one too (using python's markdown
> > > module).
> 
> There is a python script provided with mutt
> (share/doc/mutt/samples/markdown2html), which can also be found at
> https://fossies.org/linux/mutt/contrib/markdown2html . This one also
> uses pandoc.
> 
> - Jan

Thanks.

cheers,
raf

Re: Is linewrap dead?

[raf via Mutt-users]

On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson  
wrote:

> On 05Sep2022 08:24, Cameron Simpson  wrote:
> > On 04Sep2022 11:33, Kurt Hackenberg  wrote:
> > > But not space-stuffing, right?
> 
> I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh
> my brain. Yeah, I don't think I'd want that when writing a message.
> 
> > > Which I guess is why Mutt space-stuffs the format=flowed that it
> > > gets back from the editor.
> 
> Aye. I avoid lines commencing with a ">" just because they look quoted to my
> eye anyway, so that aside "live" space stuffing in authoring is something
> I'd find distracting.
> 
> Cheers,
> Cameron Simpson 

Hmm. I do "From-munging" on arrival.
I should probably read rfc3676 properly. :-)

cheers,
raf

Re: Is linewrap dead?

[raf via Mutt-users]

On Sun, Sep 04, 2022 at 08:37:21PM +1000, Cameron Simpson  
wrote:

> On 04Sep2022 15:34, raf via Mutt-users  wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson  
> > wrote:
> [...]
> > > So I've revisited the manual and found the
> > > `$send_multipart_alternative`
> > > option and its friend `$send_multipart_alternative_filter`. They work 
> > > well!
> > > 
> > > So now I have a mechanism to send: `format=flowed` MarkDown with a 
> > > aparallel
> > > HTML alternative. The HTML should render in a "paragraphy" way for the 
> > > HTML
> > > people, and the MarkDown keeps me happy.
> > > 
> > > My default setting is now:
> > > 
> > > set send_multipart_alternative=no
> > > set send_multipart_alternative_filter='echo text/html; echo; exec 
> > > md2html'
> > > 
> > > which is the inactive form, and I've added:
> > > 
> > > message-hook . 'set send_multipart_alternative=no'
> > > message-hook '%f htmlees' 'set send_multipart_alternative=no'
> > 
> > Oops. That should be =yes above.
> 
> Whoops indeed. I just sketched this out this morning. Thanks for the catch.
> fix applied.
> 
> > > The `md2html` script is my personal script, which wraps `pandoc` and
> > > post
> > > munges the HTML to indent the code blocks, which `pandoc`'s HTML does not
> > > please my eye. It's here:
> > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
> > > if anyone wants a starting point.
> > 
> > Thanks, Cameron. It's odd that there isn't an md2html
> > program out there already. I had to create one too
> > (using python's markdown module).
> 
> Ah, that might be easier to customise. I just tried a few markdown
> converters and ended up with pandoc.
> 
> > I like your indenting of code blocks, but it seems to
> > put an additional blank line after each code block.
> > That might not be intentional.
> 
> Not intentional. I just wanted to keep the 4 space indent used to trigger a
> code block for the same visual effect, since I use that instead of the
> triple backticks usually. Pandoc tosses those spaces.

That's correct behaviour for markdown. If you want the
output to be indented four spaces, the markdown source
needs to be indented eight spaces. But for email use,
it's a nice idea to do what you're doing.

If you want to prevent the extra line, the sed command
can be changed to remove theindenyt before the closing
line of the code block:

  sed '
  s/^\(\)\(.*<\/code><\/pre>\)$/\1\2/
  t post_pre_code
  /^/,/<\/code><\/pre>$/{
  s/^//
  s/^\(\)/\1/
  s/^\(<\/code><\/pre>\)/\1/
  }
  :post_pre_code
  '

> Pandoc's conversion is a bit clunky (but better than discount and the other
> tool I tried).
> 
> > And it looks like it
> > doesn't do titles (which default to "-"). I guess that
> > doesn't matter for email use, except that pandoc
> > whinges about it on stderr.
> 
> Aye, annoying. There's no context for a title (eg the subject header), I may
> just have to provide something to shut it up. Or shift sideways to the
> Python module, particularly if that does a better job.
> 
> > Do you have any advice for automating spaces at the end
> > of non-final paragraph lines for format=flowed in vim?
> 
> I use these settings:
> https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
> which autowraps and leaves trailing spaces automatically.
> 
> > Perhaps I could just post-process messages with perl
> > in my mutt-editor wrapper script.
> 
> Vim can do 99% of it for you on the fly :-)

Thanks again.

> Cheers,
> Cameron Simpson 

cheers,
raf

Re: Is linewrap dead?

[Cameron Simpson]

On 05Sep2022 08:24, Cameron Simpson  wrote:

On 04Sep2022 11:33, Kurt Hackenberg  wrote:

But not space-stuffing, right?


I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to 
refresh my brain. Yeah, I don't think I'd want that when writing a 
message.


Which I guess is why Mutt space-stuffs the format=flowed that it gets 
back from the editor.


Aye. I avoid lines commencing with a ">" just because they look quoted 
to my eye anyway, so that aside "live" space stuffing in authoring is 
something I'd find distracting.


Cheers,
Cameron Simpson 

Re: Is linewrap dead?

[Cameron Simpson]

On 04Sep2022 11:33, Kurt Hackenberg  wrote:

On 2022/09/04 06:37, Cameron Simpson wrote:

Vim can do 99% of it for you on the fly :-)


But not space-stuffing, right? Which I guess is why Mutt space-stuffs 
the format=flowed that it gets back from the editor.


I imagine it could be told to space stuff with a lot of work maybe? I 
was more thinking of the authoring side, where it word wraps and 
space-appends my input text as I type. As it's just done for me writing 
this.


Cheers,
Cameron Simpson 

Re: Re: Is linewrap dead?

[Jan Eden via Mutt-users]

On 2022-09-04 20:37, Cameron Simpson wrote:
> On 04Sep2022 15:34, raf via Mutt-users  wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson  
> > wrote:

> > > The `md2html` script is my personal script, which wraps `pandoc`
> > > and post munges the HTML to indent the code blocks, which
> > > `pandoc`'s HTML does not please my eye. It's here:
> > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if
> > > anyone wants a starting point.
> > 
> > Thanks, Cameron. It's odd that there isn't an md2html program out
> > there already. I had to create one too (using python's markdown
> > module).

There is a python script provided with mutt
(share/doc/mutt/samples/markdown2html), which can also be found at
https://fossies.org/linux/mutt/contrib/markdown2html . This one also
uses pandoc.

- Jan


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Kurt Hackenberg]

On 2022/09/04 06:37, Cameron Simpson wrote:


Do you have any advice for automating spaces at the end
of non-final paragraph lines for format=flowed in vim?


I use these settings:
https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
which autowraps and leaves trailing spaces automatically.


Perhaps I could just post-process messages with perl
in my mutt-editor wrapper script.


Vim can do 99% of it for you on the fly :-)


But not space-stuffing, right? Which I guess is why Mutt space-stuffs 
the format=flowed that it gets back from the editor.

Re: Re: Is linewrap dead?

[Nacho via Mutt-users]

> I smile, that was me. I agree with your point: email use is getting
> relegated to corporate settings, dealing with banks/utilities, some
> services (newsletters).

It's worse than that: what is being relegated by most people is reading and
writing "complex texts" (i.e. more than a few lines), and performing "complex
tasks" as attaching a few images to an email or using a paper map; this is going
backwards in the development of the Western human psyche, it's a very serious
issue, but too much off topic for this list.

Apart from that, the big difference between using whatsapp or email is that
with email you get independence: I have my own email servers using my own
domains that just a court can take away from me, use the OS and MTA of my choice
that I can modify and compile from source, set up my spam filters, webmail and
everything else just the way I want, and everything works the way I want.

It's like being the owner of my own piece of land or just a poor peasant in 
somebody's else huge land.

Re: Is linewrap dead?

[Cameron Simpson]

On 04Sep2022 15:34, raf via Mutt-users  wrote:

On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson  
wrote:

[...]
So I've revisited the manual and found the 
`$send_multipart_alternative`

option and its friend `$send_multipart_alternative_filter`. They work well!

So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel
HTML alternative. The HTML should render in a "paragraphy" way for the HTML
people, and the MarkDown keeps me happy.

My default setting is now:

set send_multipart_alternative=no
set send_multipart_alternative_filter='echo text/html; echo; exec md2html'

which is the inactive form, and I've added:

message-hook . 'set send_multipart_alternative=no'
message-hook '%f htmlees' 'set send_multipart_alternative=no'


Oops. That should be =yes above.


Whoops indeed. I just sketched this out this morning. Thanks for the 
catch. fix applied.


The `md2html` script is my personal script, which wraps `pandoc` and 
post

munges the HTML to indent the code blocks, which `pandoc`'s HTML does not
please my eye. It's here:
https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
if anyone wants a starting point.


Thanks, Cameron. It's odd that there isn't an md2html
program out there already. I had to create one too
(using python's markdown module).


Ah, that might be easier to customise. I just tried a few markdown 
converters and ended up with pandoc.



I like your indenting of code blocks, but it seems to
put an additional blank line after each code block.
That might not be intentional.


Not intentional. I just wanted to keep the 4 space indent used to 
trigger a code block for the same visual effect, since I use that 
instead of the triple backticks usually. Pandoc tosses those spaces.


Pandoc's conversion is a bit clunky (but better than discount and the 
other tool I tried).



And it looks like it
doesn't do titles (which default to "-"). I guess that
doesn't matter for email use, except that pandoc
whinges about it on stderr.


Aye, annoying. There's no context for a title (eg the subject header), I 
may just have to provide something to shut it up. Or shift sideways to 
the Python module, particularly if that does a better job.



Do you have any advice for automating spaces at the end
of non-final paragraph lines for format=flowed in vim?


I use these settings:
https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
which autowraps and leaves trailing spaces automatically.


Perhaps I could just post-process messages with perl
in my mutt-editor wrapper script.


Vim can do 99% of it for you on the fly :-)

Cheers,
Cameron Simpson 

Re: Is linewrap dead?

[raf via Mutt-users]

On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson  
wrote:

> Well, this has been quite the read.
> 
> As a plain text person (aren't we all?) I find poor quality mail clients
> annoying, as shown by the motivating screenshot of a plain text hard folder
> message presenting on a narrow portrait mode mail reader.
> 
> There seem to two approaches available: `format=flowed` which works well if
> the mail reader supports it, and HTML which is a PITA to author for us.
> 
> Having just got my `format=flowed` stuff working again after being broken
> for a long time, and have been using some Discourse forums recently (via
> email) which accept MarkDown, I've been filled with enthusiasm for MarkDown
> email. And markdown's a decent source for basic HTML, since it's authoring
> overhead is low and it is very readable in its raw form.
> 
> So I've revisited the manual and found the `$send_multipart_alternative`
> option and its friend `$send_multipart_alternative_filter`. They work well!
> 
> So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel
> HTML alternative. The HTML should render in a "paragraphy" way for the HTML
> people, and the MarkDown keeps me happy.
> 
> My default setting is now:
> 
> set send_multipart_alternative=no
> set send_multipart_alternative_filter='echo text/html; echo; exec md2html'
> 
> which is the inactive form, and I've added:
> 
> message-hook . 'set send_multipart_alternative=no'
> message-hook '%f htmlees' 'set send_multipart_alternative=no'

Oops. That should be =yes above.

> which will be turning it on for people in my (empty so far) "htmlees" mutt
> group. I use a similar pattern (`%htmlers`) for preserring HTML over plain
> text for certain messages.
> 
> The `md2html` script is my personal script, which wraps `pandoc` and post
> munges the HTML to indent the code blocks, which `pandoc`'s HTML does not
> please my eye. It's here:
> https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
> if anyone wants a starting point.
> 
> I'm probably going to bind a key to turn this mode on at some point.
> 
> Cheers,
> Cameron Simpson 

Thanks, Cameron. It's odd that there isn't an md2html
program out there already. I had to create one too
(using python's markdown module).

I like your indenting of code blocks, but it seems to
put an additional blank line after each code block.
That might not be intentional. And it looks like it
doesn't do titles (which default to "-"). I guess that
doesn't matter for email use, except that pandoc
whinges about it on stderr.

Do you have any advice for automating spaces at the end
of non-final paragraph lines for format=flowed in vim?
Perhaps I could just post-process messages with perl
in my mutt-editor wrapper script.

cheers,
raf

Re: Is linewrap dead?

[Cameron Simpson]

Well, this has been quite the read.

As a plain text person (aren't we all?) I find poor quality mail clients 
annoying, as shown by the motivating screenshot of a plain text hard 
folder message presenting on a narrow portrait mode mail reader.


There seem to two approaches available: `format=flowed` which works well 
if the mail reader supports it, and HTML which is a PITA to author for 
us.


Having just got my `format=flowed` stuff working again after being 
broken for a long time, and have been using some Discourse forums 
recently (via email) which accept MarkDown, I've been filled with 
enthusiasm for MarkDown email. And markdown's a decent source for basic 
HTML, since it's authoring overhead is low and it is very readable in 
its raw form.


So I've revisited the manual and found the `$send_multipart_alternative` 
option and its friend `$send_multipart_alternative_filter`. They work 
well!


So now I have a mechanism to send: `format=flowed` MarkDown with a 
aparallel HTML alternative. The HTML should render in a "paragraphy" way 
for the HTML people, and the MarkDown keeps me happy.


My default setting is now:

set send_multipart_alternative=no
set send_multipart_alternative_filter='echo text/html; echo; exec md2html'

which is the inactive form, and I've added:

message-hook . 'set send_multipart_alternative=no'
message-hook '%f htmlees' 'set send_multipart_alternative=no'

which will be turning it on for people in my (empty so far) "htmlees" 
mutt group. I use a similar pattern (`%htmlers`) for preserring HTML 
over plain text for certain messages.


The `md2html` script is my personal script, which wraps `pandoc` and 
post munges the HTML to indent the code blocks, which `pandoc`'s HTML 
does not please my eye. It's here:

https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
if anyone wants a starting point.

I'm probably going to bind a key to turn this mode on at some point.

Cheers,
Cameron Simpson 

Re: Re: Is linewrap dead?

[Francesco Ariis]

Il 03 settembre 2022 alle 12:33 Jan Eden via Mutt-users ha scritto:
> While I find this thread quite entertaining, we should accept that we
> are an increasingly small group of people who care not just about plain
> text email (and its formatting), but about email in general.
> 
> Over at gnupg-users, there was a recent discussion about the Washington
> Post's malformed PGP key, and one participant summarized the situation
> pretty well:
> 
> "It would be interesting to see how long the key has been there in such a
> state. If the answer is “a long time”, that is quite a field report: it
> means signal and whatsapp (!) are more popular options (way more popular
> options) than PGP + email for secure communications."
> (https://lists.gnupg.org/pipermail/gnupg-users/2022-August/066156.html)

I smile, that was me. I agree with your point: email use is getting
relegated to corporate settings, dealing with banks/utilities, some
services (newsletters).

Re: Re: Is linewrap dead?

[Jan Eden via Mutt-users]

On 2022-09-03 00:46, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote:
> > Derek Martin  wrote on Wed, 31 Aug 2022
> > at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:
> > 
> > Evaluating the strength of a SHOULD requires looking at pragmatic
> > realities. And that reality is that lots of messages are sent
> > without hard line wraps.
> 
> That's true but the vast majority of that is HTML mail, which has
> entirely different set of formatting rules and display parameters, and
> again, not applicable here.

While I find this thread quite entertaining, we should accept that we
are an increasingly small group of people who care not just about plain
text email (and its formatting), but about email in general.

Over at gnupg-users, there was a recent discussion about the Washington
Post's malformed PGP key, and one participant summarized the situation
pretty well:

"It would be interesting to see how long the key has been there in such a
state. If the answer is “a long time”, that is quite a field report: it
means signal and whatsapp (!) are more popular options (way more popular
options) than PGP + email for secure communications."
(https://lists.gnupg.org/pipermail/gnupg-users/2022-August/066156.html)

This is obviously not limited to *secure* communications (as many
people do not care about security).

Apologies for the digression.

- Jan


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Derek Martin]

On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote:
> Derek Martin  wrote on Wed, 31 Aug 2022
> at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:
> 
> Evaluating the strength of a SHOULD requires looking at pragmatic
> realities. And that reality is that lots of messages are sent
> without hard line wraps.

That's true but the vast majority of that is HTML mail, which has
entirely different set of formatting rules and display parameters, and
again, not applicable here.

> Also, RFC5322 is not intended to be a standard that governs what
> user should do. It's for MTAs and MUAs and other mail software.

This is clearly not true, since it is the standard for the format of
the message, and the stated purpose is to ensure that recipients are
not negatively impacted by

 implementations of user interfaces that display these messages
 which may truncate, or disastrously wrap, the display of more
 than 78 characters per line.

This isn't about transmission, it's about interface and display. The
user, far more than the MUA, controls the format of the message by how
they construct the message, which in your case does indeed
"disastrously wrap, the display of more than 78 characters per line"
on my end.  Your MUA does nothing to correct it--though I could force
mine to. But as you say, it's extra work that is annoying, and I've
only even seen people do what you're doing a handful of times since
the 80's... usually by accident, or because they were brand-new e-mail
users unfamiliar with the etiquette...

And for the record, of the 8 people posting in this subthread
(starting with your post), 2 of them complained about your practice.
Perhaps your messages aren't as universally readable as you think.

Anyway, the reason this conversation ultimately never goes anywhere
useful is because there's already a perfectly viable means of
achieving your goal: HTML mail.  Pretty formatting is literally what
it's for, and unlike format=flowed, or anything else you can imagine,
it's already widely adopted.  That fact is largely why nothing else
will ever will be (at least until the next new thing is invented with
capabilities far superseeding HTML).  If you're so concerned with ugly
wrapping, that's what you should be using.  Otherwise, you should wrap
your lines like the standards and existing conventions say you should.
If it's just jagged right margins you don't like that's easily fixed
by justifying the text in your editor--solutions exist for common
editors, google them.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Marcelo Laia]

It not worked as expected

https://pasteboard.co/ZP492mei7cBc.jpg

Marcelo

Enviado a partir de dispositivo móvel

Em qui., 1 de set. de 2022 16:42, Marcelo Laia 
escreveu:

> Hi José Maria,
>
> I am doing a test.
>
> In this message, I seted in vimrc this lines:
>
>
> set wrap
> set linebreak
>
> Here, I will post a lot off words to test.
>
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
> veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
> commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
> velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
> occaecat cupidatat non proident, sunt in culpa qui officia deserunt
> mollit anim id est laborum.
>
> Marcelo
>
> On 29/08/22 at 09:59, José María Mateos wrote:
> > On Mon, Aug 29, 2022 at 03:43:37PM +0200, Angel M Alganza wrote:
> > > Perhaps if there was a way to configure Mutt to wrap long lines while
> > > reading mail with them and Vim to do the same (visually but not
> actually
> > > including the new lines) while editing they would be bearable for us
> who
> > > preffer wrapped mail?
> >
> > You can do that. For mutt:
> >
> > unset markers
> > set wrap = 78
> >
> > That'll wrap long lines at 78 characters and won't use markers to show
> where
> > a line was wrapped (I found that quite distracting.)
> >
> > For vim, you can enable soft line wrapping. For example:
> > https://vim.works/2019/03/16/wrapping-text-in-vim/
> >
> > I think this is what you mean in your message, at least. This won't wrap
> any
> > text lines and will leave the client to deal with it as it sees fit. On
> > mutt's side, it'll wrap long lines at the 78 char mark.
> >
> > Cheers,
> >
> > --
> > José María (Chema) Mateos || https://rinzewind.org
>
> --
> Marcelo
>

Re: Is linewrap dead?

[Marcelo Laia]

Hi José Maria,

I am doing a test.

In this message, I seted in vimrc this lines:


set wrap
set linebreak

Here, I will post a lot off words to test.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum.

Marcelo

On 29/08/22 at 09:59, José María Mateos wrote:
> On Mon, Aug 29, 2022 at 03:43:37PM +0200, Angel M Alganza wrote:
> > Perhaps if there was a way to configure Mutt to wrap long lines while
> > reading mail with them and Vim to do the same (visually but not actually
> > including the new lines) while editing they would be bearable for us who
> > preffer wrapped mail?
> 
> You can do that. For mutt:
> 
> unset markers
> set wrap = 78
> 
> That'll wrap long lines at 78 characters and won't use markers to show where
> a line was wrapped (I found that quite distracting.)
> 
> For vim, you can enable soft line wrapping. For example:
> https://vim.works/2019/03/16/wrapping-text-in-vim/
> 
> I think this is what you mean in your message, at least. This won't wrap any
> text lines and will leave the client to deal with it as it sees fit. On
> mutt's side, it'll wrap long lines at the 78 char mark.
> 
> Cheers,
> 
> -- 
> José María (Chema) Mateos || https://rinzewind.org

-- 
Marcelo

Re: Is linewrap dead?

[Kurt Hackenberg]

On 2022/09/01 09:31, Mark H. Wood wrote:


 From my POV, when someone uses one of those MUAs that think a
paragraph and a line are the same thing, that person's emails make
more work for me, and I find the person annoying.

"More work" means, for example, that if I try to quote such a
"paragraph", and I touch it at all, emacs re-wraps it without
inserting the necessary additional quotation brokets and I have to add
them by hand.  There's probably a way to fix that, but I can't be
bothered to rotate, I mean, adjust it.


Sounds like you have auto-fill-mode on. You might want to turn that off 
for those long-line messages.


Or, you could make Emacs fill those quotes correctly by using the 
command C-x . (set-fill-prefix).


You might want to read the manual section about filling text, and not 
only for those long-line messages. Emacs only semi-automates filling 
text, which I think is kind of clunky, but it has uses.

Re: Is linewrap dead?

[Mark H. Wood]

On Wed, Aug 31, 2022 at 06:35:15PM -0500, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 04:38:11PM -0400, John Hawkinson wrote:
> > (b) Even if recipients *do* rotate, they will still have the
> > subconscious/psychological result that "Dealing with Derek's emails
> > takes more work, he is annoying."
> 
> That, arguably, would be my problem, but in 33 years of using e-mail,
> has never been.  Not once.  Not because of the way I format e-mail, at
> any rate... =8^)

This does happen, but I beg to point out that it happens *both* ways.
From my POV, when someone uses one of those MUAs that think a
paragraph and a line are the same thing, that person's emails make
more work for me, and I find the person annoying.

"More work" means, for example, that if I try to quote such a
"paragraph", and I touch it at all, emacs re-wraps it without
inserting the necessary additional quotation brokets and I have to add
them by hand.  There's probably a way to fix that, but I can't be
bothered to rotate, I mean, adjust it.

So this sword really does cut both ways.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Mark H. Wood]

On Wed, Aug 31, 2022 at 02:48:55PM -0500, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 01:46:49PM -0400, John Hawkinson wrote:
> > As for standards-compliance, that's a red herring. Long lines are
> > not going to trip up any modern client, they're just not.
> 
> It may be less relevant today, but it's still relevant.  While the
> original reason for the standard was that the myriad of clients would
> display long lines improperly or not at all, these days it's not
> really about clients.  Sendmail truncates lines at 998 characters.  It
> is not alone.
> 
> [It's conceivable this has become untrue since last I checked, but I
> doubt it, and assuming so is not wise.  Besides which, I'd be shocked
> to discover that all internet sites are on the most modern versions of
> their MTAs. It just doesn't happen.]

Indeed, it is the MTAs, not the MUAs, that will balk at looong lines.
Exim OOTB (at least, on Gentoo) is configured to be quite unforgiving
about it.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[raf via Mutt-users]

On Thu, Sep 01, 2022 at 08:20:21AM +0200, Angel M Alganza  wrote:

> On Wed, Aug 31, 2022 at 05:22:48PM -0400, Kurt Hackenberg wrote:
> 
> > Very long lines -- one line per paragraph -- changes the meaning of
> 
> After top posting that is probably the most annoying thing on email.
> And from what I can tell reading this thread, there will always be some
> nasty software and some people who will insist on doing that.
> 
> So, is there a way to instruct Mutt to wrap received mail with long
> lines to wrap them for me at a sane length so that I don't have to suffer
> those ridiculous long lines?

I have this in ~/.muttrc:

  set markers = no
  set wrap = -5

which wraps lines at 5 columns in from the right. You can
also use a positive number to specify an absolute amount.
Turning markers off means that wrapped lines won't start with
a "+" character. HAving the + there might be preferable. I
remove them so I can copy and paste multi-line wrapped URLs
into another window to be opened locally (the email is read
remotely via ssh to a vm).

So maybe try something like:

  set wrap = 72
  set smart_wrap

There are other muttrc variables to look into: e.g. smart_wrap
That looks good. I might add that. It wraps at word boundaries.

> Of course I can reduce the with of the frame on Notion (my window
> manager) where I run Mutt to force the wrapping, but I'd rather keep the
> size I use for everything else and have Mutt wrapping the text for me.
> 
> Cheers.
> Ángel

cheers,
raf

Re: Is linewrap dead?

[Bastian]

First, I'd like to thank Tavis for starting this discussion. I am very 
pleased to see I am not the only one struggling with this.

On 29Aug22 13:28-0400, Logan Rathbone wrote:
> FWIW, the solution/compromise I ended up using was to compose
> multipart/alternative mails with mutt, sending a very simple HTML mail
> and a standard hard-wrapped text-based mail as well. So mobile
> mailreaders can read it perfectly, and desktop users can read the
> plaintext version correctly as well.
> 
> Believe it or not, mutt actually has very sophisticated functionality to
> achieve this, and even comes with a sample script called markdown2html
> to assist with this. I tend to write plaintext mails using a subset of
> markdown *anyway*, so it works out very well.
> 
> And since sending such mails would obviously annoy certain people (eg,
> the users of this ML!) I have mutt set up to prompt if I want to send as
> multipart/alternative defaulting to no, as in:
> 
> set send_multipart_alternative = ask-no

Thanks for that pointer! I am what you might say a true believer in 
text/plain. OTOH, the world is very diverse, and looking only into one 
direction makes me feel missing other people out there. So I tend to 
like this multipart approach.

-- 
Bastian

Re: Is linewrap dead?

[Angel M Alganza]

On Wed, Aug 31, 2022 at 05:22:48PM -0400, Kurt Hackenberg wrote:

Very long lines -- one line per paragraph -- changes the meaning of 


After top posting that is probably the most annoying thing on email.
And from what I can tell reading this thread, there will always be some
nasty software and some people who will insist on doing that.

So, is there a way to instruct Mutt to wrap received mail with long
lines to wrap them for me at a sane length so that I don't have to suffer
those ridiculous long lines?

Of course I can reduce the with of the frame on Notion (my window
manager) where I run Mutt to force the wrapping, but I'd rather keep the
size I use for everything else and have Mutt wrapping the text for me.

Cheers.
Ángel

Re: Is linewrap dead?

[raf via Mutt-users]

On Wed, Aug 31, 2022 at 02:48:55PM -0500, Derek Martin  
wrote:

> The bottom line is there is absolutely no reason why hard-wrapped
> lines of plain text at 72 characters should ever need to display
> unreadably for any desktop user, or even anyone on any reasonable
> mobile device which can rotate lines parallel to their longer side,
> that doesn't boil down to the choice of the user.  Flouting the
> standards is a bad habit to be in.  They exist for good reason; if you
> choose to abandon them you do so at your own peril, and the rest of us
> should not be expected to accommodate you.
> 
> -- 
> Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
> -=-=-=-=-

I hard wrap at 55 to leave plenty of room for later
quoting. I often receive replies from MUAs that wrap
quoted text badly (as though they don't know what
quoted text is) and so I try to reduce the likelihood
of that.

Strangely, it seems that some MUAs that treat each line
as a paragraph seem to insert an additional newline
after each line in what they quote as part of a reply,
so I receive replies with a quoted blank line between
each original line. It's almost as though they want to
think that each line is a separate paragraph on input,
but they're not entirely convinced, so for output, they
make sure it's a "real" paragraph by adding a blank
line between each input "paragraph". It doesn't make a
lot of sense. Either a newline marks a paragraph or it
doesn't. They can't make up their minds.

I sometimes spend time cleaning up this sort of thing
(or just removing quote trails), but it would never
occur to me to complain to the sender about the
formatting of their email. There's no point.

Similarly, noone has ever complained about my emails.
They might (or might not) have seen them as untidy, but
I don't agree that that makes them any less effective
as a means of communication. And I wouldn't worry about
a recipient thinking that my emails aren't as nice as
someone else's. The content of one person's emails
would never be the same as the content of someone
else's emails, so there is no meaning to any comparison
like that.

The best definition of technology that I ever heard
was: "Anything that doesn't work properly yet". Once
technology works properly, we give it a permanent name
like chair, or hammer, or pencil. :-) So it's best if
everyone just cuts everyone else a lot of slack when it
comes to what technology does to our written
communications. If someone has too much trouble doing
that, for whatever reason (and I'm sure there are valid
reasons), and they are receiving emails that do bother
them to read, they could consider not reading emails on
phones. There are many other reasons to not read email
on phones. This might just be another one. Even
excluding the whole short attention-span dopamine
training thing, I know someone who is often very
frustrated with the mail app on their iphone for often
not being able to display emails that it composed and
sent, complaining that the sender created a malformed
email (a bug people have complained about for 10+ years
that shows no sign of every being fixed), or emails
from one person that are displayed with a different
person altogether as the sender). In the grand scheme
of things, lines that aren't all the same length seems
unimportant. But it's obviously fun to talk about. :-)

It would have been great if all of the obvious suspects
had been willing at any point in the last 20+ years to
pay just one of their many thousands of programmers to
spend a little time to implement format=flowed. That
would be the best solution to this "problem". But it
seems they really really don't want that solution to
exist for some reason best known only to themselves. I
don't think it's fair or reasonable to blame the
senders of emails for a problem caused by the company
that created the deliberately limited MUA that the
recipient uses, let alone expect those senders to all
individually solve the problem. I'd use format=flowed
if there was any point, but it doesn't seem that there
is. It never makes sense to expect a large number of
entities to each solve a problem that could be solved
by a tiny number of (more powerful) entities. It's just
not efficient or practical or likely to work reliably.

cheers,
raf

Re: Is linewrap dead?

[Tim Chase]

On 2022-08-31, Tavis Ormandy wrote:
> If it was up to me I'd continue using
> tw=72, but sometimes a compromise
> is necessary.

Perhaps tw=40 would be sufficient to
make everybody happy.  Reminds me a bit
of my old Apple, ][+ days with 40-column
upper-case only.

;-)

-tkc

Re: Is linewrap dead?

[John Hawkinson]

Derek Martin  wrote on Wed, 31 Aug 2022
at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:

> > I don't really think we're flouting the standards.
> 
...
> So it IS only a recommendation, not a requirement--but it's a pretty
> strong recommendation, and either way you're still flouting it.

No. Flouting a recommendation in a standard is not flouting the standard.
Pleae don't twist my words.

(If you want to be pedantic, you may accuse me of flouting a SHOULD 
recommendation within a standard, and I will admit to it, but I think such a 
contextless admission misses the point.)

Evaluating the strength of a SHOULD requires looking at pragmatic realities. 
And that reality is that lots of messages are sent without hard line wraps.

Furthermore, if the choice were between standards-compliance and readable 
emails by more recipients, most of us would choose the pragmatic choice of 
readable emails. That's not to say we are faced with such a stark choice -- it 
is far more nuanced and a matter of opinion and individual judgment.

Also, RFC5322 is not intended to be a standard that governs what user should 
do. It's for MTAs and MUAs and other mail software. That, of course, speaks to 
the nuanced and pragmatic analysis.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Derek Martin]

On Wed, Aug 31, 2022 at 04:38:11PM -0400, John Hawkinson wrote:
> I don't mean to monopolize the conversation, but:
> 
> Derek Martin  wrote on Wed, 31 Aug 2022
> at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>:
> 
> > I don't see why this matters, because as I already pointed out, any
> > desktop GUI MUA will have no trouble displaying 72 character lines
> > wrapped as they are, and any *reasonable* mobile can do the same by
> > rotating it.
> 
> (1) I do not agree that it is reasonable to expect mobile users to
> rotate their screens.

That's merely your opinion, which you are entitled to.  Being
unwilling to make the smallest effort to rotate your screen, when it
will give you optimal reading conditions, seems like the definition of
"unreasonable" to me.

> (a) I think many won't do it

That is their choice, for which they may live with the consequences.
Not my problem.

> (b) Even if recipients *do* rotate, they will still have the
> subconscious/psychological result that "Dealing with Derek's emails
> takes more work, he is annoying."

That, arguably, would be my problem, but in 33 years of using e-mail,
has never been.  Not once.  Not because of the way I format e-mail, at
any rate... =8^)

> (2) On desktop GUIs, emails will be readable, but they will look
> different from most other sender's emails. This again becomes a
> variant of (1)(b).

I think you are projecting a level of unadaptability on people that is
uncommon.  In any case, that, too, is not my problem...  It's their
choice, their consequences, as I keep saying.  If they actually tried
it, I dare say many if not most might find it preferable.

> I think we can all accept that when people have to do more work

I find the notion that turning your wrist slightly an amount of extra
work that even bears consideration laughable.  Exception granted for
folks who have physical limitations which make that difficult or
impossible, but I'm betting such people aren't reading e-mail on a
phone.

> > There actually is significant psychological research into the ideal
> > line length for reading. There's some variation, but the consensus
> > seems to come in at about 60-75 characters, at a width of roughly
> > 4-5".
> 
> Sure, but this assumes a lot of things.

To be clear, we're talking about plain text e-mail here, since this
discussion is irrelevant for variable-width HTML mail. My assumptions
are pretty safe, at least for every GUI client I occasionally use,
which thankfully does not include Outlook, so can't speak to that.

Your belief that using long lines is fine also assumes a lot of
things, about the MUA, MTA, and MDA software in use by you--wherever
you may be sending it from--and by all of your recipients, not to
mention any custom tools they may be using to process it.  Safe enough
for typical users--less so for atypical users--like most of the folks
on this list. =8^)

> > > As for standards-compliance, that's a red herring. Long lines are
> > > not going to trip up any modern client, they're just not.
> > 
> > It may be less relevant today, but it's still relevant.  
> 
> As noted by Kurt, this is up to the MUA to address, and is easily
> fixed by encoding as quoted-printable. Probably other ways too.

That's technically true but anything that can send mail is technically
a MUA, and may or may not be capable of automatically converting your
garbage in into lovely standards-compliant data out.  Suppose you
suddently have a need to send e-mail programmatically... You're in the
habit of sending long lines because you're convinced it's
"better"--will the tools you use care?  Maybe.  Maybe not.  Will it
matter?  That depends on whether the e-mail you send matters, and
maybe how time-sensitive it is...

> > lines of plain text at 72 characters should ever need to display
> > unreadably for any desktop user, or even anyone on any reasonable
> > mobile device which can rotate lines parallel to their longer side,
> 
> Hard disagree. People don't always rotate, shouldn't have to, and
> will resent it when forced to do so.

Again their choice, but fine--I will not, and should not have to
change the way I compose e-mail from well-established standards and
conventions, and will resent it if you try (and ultimately fail) to
force me to.  So where does that leave you?  Rotating your phone is BY
FAR the easiest, most practical and economical solution to that
conundrum.  Choose to or not, it's on you.

> I don't really think we're flouting the standards.

You're already aware that RFC 5322 (and a bunch of others) recommends
keeping line lengths below 78 characters, and you're willfully
dismissing that recommendation, so by definition yes you are.  But
conventions are also standards, and your failure to comply with
established conventions may be causing difficulty for people who are
doing some sort of automated processing of their mail which expects
those conventions. So again, yes.

And for the record, RFC 2119 says this about "SHOULD":

Re: Is linewrap dead?

[Derek Martin]

On Wed, Aug 31, 2022 at 05:43:41PM -0400, John Hawkinson wrote:
> John Hawkinson  wrote on Wed, 31 Aug 2022
> at 16:38:11 EDT in :
> 
> > I suppose I should send some 2,000-character paragraph emails as
> > tests to see what happens, but I very much doubt there will be
> > problems as a result.
> 
> Anyhow, if I send a 2,000-character line in mutt, it encodes it in
> quoted-printable.  So no standards problem.

This is precisely what's concerning--you seem to think that this
covers all the reasons why the standard exists, and the convention
persists.  That's the farthest thing from true.  Mutt is not the ony
thing that sends mail, and you have no idea what's happening in all
the myriad of other things that do; nor do you on the receiving end or
on any of the recipients, which may include custom tools that are
thwarted by your refusal to adhere to the established convention.

To be clear, I have no issue with YOU not wrapping your lines in mail
you send with Mutt--after this thread ends I will just happily ignore
your messages, since I find them annoying to deal with.  It's the fact
that you're actively advocating ignoring the standards as a general
practice, possibly to the detriment of those who may be using e-mail
differently than you are, who might be negatively impacted by doing
so, or their recipients, as a result.  That I find completely
unacceptable.

> Can we please move back to...I don't even know. Other suggestions on
> ways to handle the problem of devices that don't display
> hard-wrapped text well?

There are no such devices, except those which are too small to display
e-mail readably in the first place, so not worth considering.  Beyond
that there are only ones which some users may stubbornly refuse to use
effectively. But in any case, no!  Or to be more precise, you can
discuss them all you like, but they won't happen, just as
format=flowed has already failed (which TBH I find unfortunate).  All
you could possibly succeed in doing is to convince a few more people
to send messages that are annoyingly hard to read in text-based
clients, and risk transmission failure when they attempt to do so
outside the extremely well-behaved confines of Mutt.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Kurt Hackenberg]

On Wed, Aug 31, 2022 at 05:43:41PM -0400, John Hawkinson wrote:


Very long lines -- one line per paragraph -- changes the meaning of 
ASCII/Unicode.


err, what? I am confused what we are discussing.


ASCII was not designed to be automatically word-wrapped. The idea was 
that a line keeps going off to the right until a CR character. 
Microsoft and Apple decided long ago to do something different, and 
effectively change the definition of the character set a little.


I think it was associated with the move to GUIs, and many windows of 
widely varying sizes, including text dialog boxes. It was a real 
problem, of course -- as we see now, fixed-length lines don't really 
work when displayed at varying width. One line per paragraph and 
automatic word-wrap is a fairly simple solution, and works pretty 
well, but it's a redefinition, and incompatible.



I could live with that if it were labelled, with a new MIME subtype, but I 
agree that a new subtype probably


And even more so here.


There could be a new subtype of text, maybe text/paragraph, to label 
body parts that should be interpreted that way. Apparently something 
like that was proposed about 20 years ago, but it didn't happen.

Re: Is linewrap dead?

[John Hawkinson]

Kurt Hackenberg  wrote on Wed, 31 Aug 2022
at 17:22:48 EDT in <2d716370-8c96-adcf-11d4-939a3f808...@panix.com>:

> > I don't really think we're flouting the standards.
> 
> Very long lines -- one line per paragraph -- changes the meaning of 
> ASCII/Unicode.

err, what? I am confused what we are discussing.

> I could live with that if it were labelled, with a new MIME subtype, but I 
> agree that a new subtype probably

And even more so here.

John Hawkinson  wrote on Wed, 31 Aug 2022
at 16:38:11 EDT in :

> I suppose I should send some 2,000-character paragraph emails as tests to see 
> what happens, but I very much doubt there will be problems as a result.

Anyhow, if I send a 2,000-character line in mutt, it encodes it in 
quoted-printable.
So no standards problem.

Can we please move back to...I don't even know. Other suggestions on ways to 
handle the problem of devices that don't display hard-wrapped text well? I 
mean, at the moment, the choices are:

(a) hard-wrap the lines
(b) don't wrap the lines at all (my preference)
(c) format=flowed, which works approximately nowhere that (a) doesn't

It's a good thing no one is proposing a different set of defaults for mutt.

Oh maybe we're discussing how to accomplish these things in vim or Emacs? I 
dunno, again.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Kurt Hackenberg]

On 2022/08/31 16:38, John Hawkinson wrote:


I don't really think we're flouting the standards.


Very long lines -- one line per paragraph -- changes the meaning of 
ASCII/Unicode.


I could live with that if it were labelled, with a new MIME subtype, but 
I agree that a new subtype probably will not be accepted by the large 
makers of mail readers. It would be easy for them -- they'd just have to 
put a label on what they already do -- but they're not likely to do it 
without something pushing them.


I guess we could try to persuade the IETF. Apparently that failed once, 
about 20 years ago, but smartphones didn't exist then.


The large companies are not likely to implement format=flowed either, if 
they haven't already. Thunderbird implements it, and Thunderbird is 
fairly popular on Unix systems, but Thunderbird is probably 1% as big as 
Microsoft Outlook. I guess Mutt is even smaller.

Re: Is linewrap dead?

[John Hawkinson]

I don't mean to monopolize the conversation, but:

Derek Martin  wrote on Wed, 31 Aug 2022
at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>:

> I don't see why this matters, because as I already pointed out, any
> desktop GUI MUA will have no trouble displaying 72 character lines
> wrapped as they are, and any *reasonable* mobile can do the same by
> rotating it.

(1) I do not agree that it is reasonable to expect mobile users to rotate their 
screens.
(a) I think many won't do it (I don't usually have rotation enabled, for 
instance, because it leads to nuisance rotation. That means I have to unlock 
rotation to make it happen, which is annoying.)
(b) Even if recipients *do* rotate, they will still have the 
subconscious/psychological result that "Dealing with Derek's emails takes more 
work, he is annoying."
(2) On desktop GUIs, emails will be readable, but they will look different from 
most other sender's emails. This again becomes a variant of (1)(b).

> > What tends to happen is those people psychologically view
> > hard-wrapped 72-char emails as ugly and they become a far less
> > effective means of communication than other people's emails are,
> > regardless of conscious choice.
> 
> This is unscientific nonsense.

[[citation needed]]

I think we can all accept that when people have to do more work to accomplish a 
task for Person A versus Person B, they can come to resent Person A. I'm sure 
we can dig up social science research on this topic generally, but is it really 
necessary?

> There actually is significant psychological research into the ideal
> line length for reading. There's some variation, but the consensus
> seems to come in at about 60-75 characters, at a width of roughly
> 4-5".

Sure, but this assumes a lot of things. It assumes reasonably-formatted columns 
widths and vieport spaces, etc. It assumes we're not comparing fixed-width 
fonts to proportional ones and plai ntext versus HTML emails and all kidns of 
related issues. I very much doubt that these assumptions generally hold.

> > As for standards-compliance, that's a red herring. Long lines are
> > not going to trip up any modern client, they're just not.
> 
> It may be less relevant today, but it's still relevant.  

As noted by Kurt, this is up to the MUA to address, and is easily fixed by 
encoding as quoted-printable. Probably other ways too.


> The bottom line is there is absolutely no reason why hard-wrapped
> lines of plain text at 72 characters should ever need to display
> unreadably for any desktop user, or even anyone on any reasonable
> mobile device which can rotate lines parallel to their longer side,

Hard disagree. People don't always rotate, shouldn't have to, and will resent 
it when forced to do so.

It may well be that some people aren't bothered, as you posit, but it's 
certainly not all people, and I would suggest it is not even close to the 
majority.


> that doesn't boil down to the choice of the user.  Flouting the
> standards is a bad habit to be in.  They exist for good reason; if you
> choose to abandon them you do so at your own peril, and the rest of us
> should not be expected to accommodate you.

I don't really think we're flouting the standards.

I suppose I should send some 2,000-character paragraph emails as tests to see 
what happens, but I very much doubt there will be problems as a result.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Tavis Ormandy]

On 2022-08-31, Derek Martin wrote:
>> That'd be true if we were sending emails to ourselves
>> but a lot of us send email to people who read their mail primarily
>> or exclusively on phones and in desktop GUIs that don't approximate
>> 72-chars.
>
> I don't see why this matters, because as I already pointed out, any
> desktop GUI MUA will have no trouble displaying 72 character lines
> wrapped as they are, and any *reasonable* mobile can do the same by
> rotating it.

If this works for you, then you're very lucky! I don't think this will
work for me.

I could tell the people asking me why my email looks funny that my mail
must be read in landscape orientation, but I think they will just make a
note to avoid asking me questions in future. I would like to avoid that.

If it was up to me I'd continue using tw=72, but sometimes a compromise
is necessary.

Tavis.

-- 
 _o)$ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger tav...@sdf.org
_\_V _( ) _( )  @taviso

Re: Is linewrap dead?

[Derek Martin]

On Wed, Aug 31, 2022 at 07:57:43PM +0200, Francesco Ariis wrote:
> > The problem is popular modern mobile and web-based MUAs don't handle
> > this and can make unexpected linewrap decisions. It's no issue when
> > emailing UNIX nerds, but non-nerds think I'm doing something wrong.
> 
> I do not have a smartphone, can I ask someone to provide a .png on
> how this or other similar messages look on a smartphone client? I am
> very curious and hopefully a definite guideline will pop up from this
> thread.

There is already a well-established guideline:  Wrap lines at ~70-72
characters.  Here's a screenshot of what that looks like (one of the
earlier messages I posted in this thread) on my mobile, properly
rotated to be able to read it.

  http://www.pizzashack.org/images/mail.png
 
If you think that has any sort of readability issue, I would encourage
you to discuss that with a psychologist.  From a scientific
standpoint, I mean... =8^)

Also don't forget to actually look at the image on your phone.  The
scale will obviously be out of whack if you view it on a desktop (but
the readability will still not)!


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Derek Martin]

On Wed, Aug 31, 2022 at 01:46:49PM -0400, John Hawkinson wrote:
> Derek Martin  wrote on Wed, 31 Aug 2022
> at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>:
> 
> > It's been my experience that if you read your mail on anything other
> > than a phone, the 72-character line width is fine, and even on a phone
> > if you turn it sideways it's still fine.  My preferred solution, then,
> > has been to stick with following the standards and assume that if you
> > insist on reading mail on a hand-held device that can't accommodate
> > the standard, and/or refuse to rotate it so that it can, then you get
> > what you get, it's your choice and the consequences of your choice are
> > on you.
> 
> That'd be true if we were sending emails to ourselves
> but a lot of us send email to people who read their mail primarily
> or exclusively on phones and in desktop GUIs that don't approximate
> 72-chars.

I don't see why this matters, because as I already pointed out, any
desktop GUI MUA will have no trouble displaying 72 character lines
wrapped as they are, and any *reasonable* mobile can do the same by
rotating it.

Where there IS significant difficulty, however, is with lines that
wrap unevenly, because the display is too narrow to display the whole
line, as well as with lines that are too long.  Neither mobile nor
desktop clients inherently impose this problem on their users; but YOU
do, when you choose to manually wrap your lines either too long or too
short, or not at all.

If, as the user, your complaint is extra white space at the end of the
line, increase the font size (either desktop or mobile) or change the
width of your desktop client.  That, too, is a choice that's on you.
If your issue is that you have to make the text too big to fit so you
can read it, then either you need to update the prescription of your
glasses so you can make the text smaller, or if that's not a viable
fix for you, then you have simply made the wrong choice of device for
your needs.

> What tends to happen is those people psychologically view
> hard-wrapped 72-char emails as ugly and they become a far less
> effective means of communication than other people's emails are,
> regardless of conscious choice.

This is unscientific nonsense.  There actually is significant
psychological research into the ideal line length for reading. There's
some variation, but the consensus seems to come in at about 60-75
characters, at a width of roughly 4-5".  I won't cite sources because
they are ubiquitous; you can google them yourself.  Long lines cause
problems for readers because the length makes it difficult to find
where (vertically) the lines begin and end.  Short lines cause
problems because of too much scanning back and forth, breaking the
reader's rhythm.  Works well for poetry (where the rhythm is largely
the point), but not much else.

Nearly all modern hand-helds are within a reasonable margin of being
4-5" long, and can easily display 75-character lines within their
length, so again rotating the phone makes it perfectly readable, and
actually provides pretty close to optimal reading conditions.  Anyone
who's reading e-mail regularly on a Nokia 8210 is an idiot, and
deserves what they get for intentionally choosing to do something so
idiotically counterproductive.

> It's great if you can choose the people who read your emails

I don't know anyone in that boat; and even if I did, it doesn't
counter a single thing I've said.

> As for standards-compliance, that's a red herring. Long lines are
> not going to trip up any modern client, they're just not.

It may be less relevant today, but it's still relevant.  While the
original reason for the standard was that the myriad of clients would
display long lines improperly or not at all, these days it's not
really about clients.  Sendmail truncates lines at 998 characters.  It
is not alone.

[It's conceivable this has become untrue since last I checked, but I
doubt it, and assuming so is not wise.  Besides which, I'd be shocked
to discover that all internet sites are on the most modern versions of
their MTAs. It just doesn't happen.]

But as for the clients, Kurt is correct that modern clients will use
QP format to avoid long lines. But that doesn't help you if you are
stuck using a legacy client you don't have control over for whatever
reason (as a former sysadmin I've seen this type of problem more times
than I can count), or generate messages via a script that sends the
body directly to sendmail, etc..

The bottom line is there is absolutely no reason why hard-wrapped
lines of plain text at 72 characters should ever need to display
unreadably for any desktop user, or even anyone on any reasonable
mobile device which can rotate lines parallel to their longer side,
that doesn't boil down to the choice of the user.  Flouting the
standards is a bad habit to be in.  They exist for good reason; if you
choose to abandon them you do so at your own peril, and the rest of us
should not be 

Re: Is linewrap dead?

[Tavis Ormandy]

On 2022-08-30, Jan Eden via Mutt-users wrote:
> Apart from the known drawbacks of HTML mail, the markdown2html script
> has a couple of requirements to further complicate my (already overly
> complex) mailstack.

Yep, I can understand that. I think the best option might be piping your
mail through `par w998`, that should look just fine on mobile.

I've just been doing it in vim before I :wq.

I haven't decided if I'm sticking with markdown2html yet, I think with
some hacking it would be acceptable (I don't like some of the
preprocessing).

Tavis.

-- 
 _o)$ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger tav...@sdf.org
_\_V _( ) _( )  @taviso

Re: Is linewrap dead?

[Francesco Ariis]

John,

Il 31 agosto 2022 alle 14:05 John Hawkinson ha scritto:
> Here's an inlined PNG showing how your email displayed for me in the
> Android Gmail app.
> Note the short lines like "clients my emails" and "provide a .png on". It
> could certainly be worse (and it often is), but it's not great:

many thanks!

It is the first time I see this and am both amused and distressed.
Indeed it is not good and could get quite annoying quite fast. Definitely
a no-no for job-related emails too.

I will keep a close eye on this thread: smartphones are ubiquitous,
One True Way™ to mitigate this problem would be really appreciated
—F

Re: Is linewrap dead?

[John Hawkinson]

Francesco Ariis  wrote on Wed, 31 Aug 2022
at 13:57:43 EDT in :

> I do not have a smartphone, can I ask someone to provide a .png on
> how this or other similar messages look on a smartphone client? I am
> very curious and hopefully a definite guideline will pop up from this

I sent a previous version of this email with inlined PNG, but of course the 
list software marked it for moderation. See the image at
https://imgur.com/TUfUy82.

which shows how your email displayed for me in the Android Gmail app. Note the 
short lines like "clients my emails" and "provide a .png on". It could 
certainly be worse (and it often is), but it's not great.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Kurt Hackenberg]

On Wed, Aug 31, 2022 at 12:39:42PM -0500, Derek Martin wrote:

I can't say I know how various MTAs handle lines longer than 998 
characters, but I would expect at least a subset would either 
truncate them or reject your message... or at least that it would be 
wise to assume so.


Mail readers that generate long-line paragraph-style text, encode it 
with quoted-printable, so they can insert QP soft line breaks to stay 
under 998 characters. Usually they insert those soft line breaks about 
every 70-80 characters, sometimes rigidly at some exact number, even 
in the middle of a word. The user doesn't see that, of course.


My preferred solution, then, has been to stick with following the 
standards...


The corporate behemoths in this field -- Microsoft, Apple, Google -- 
have invented their own standard, and don't think there are enough of 
us to care about.  They have 3 or 4 billion users.

Re: Is linewrap dead?

[Francesco Ariis]

Hello everyone,

Il 29 agosto 2022 alle 00:28 Tavis Ormandy ha scritto:
> The problem is popular modern mobile and web-based MUAs don't handle
> this and can make unexpected linewrap decisions. It's no issue when
> emailing UNIX nerds, but non-nerds think I'm doing something wrong.

I am quite surprised by this. I remember on web clients my emails
to be narrow but readable and certainly not looking wrong.

I do not have a smartphone, can I ask someone to provide a .png on
how this or other similar messages look on a smartphone client? I am
very curious and hopefully a definite guideline will pop up from this
thread.

Thanks all
—F

Re: Is linewrap dead?

[John Hawkinson]

Derek Martin  wrote on Wed, 31 Aug 2022
at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>:

> It's been my experience that if you read your mail on anything other
> than a phone, the 72-character line width is fine, and even on a phone
> if you turn it sideways it's still fine.  My preferred solution, then,
> has been to stick with following the standards and assume that if you
> insist on reading mail on a hand-held device that can't accommodate
> the standard, and/or refuse to rotate it so that it can, then you get
> what you get, it's your choice and the consequences of your choice are
> on you.

That'd be true if we were sending emails to ourselves, but a lot of us send 
email to people who read their mail primarily or exclusively on phones and in 
desktop GUIs that don't approximate 72-chars.

What tends to happen is those people psychologically view hard-wrapped 72-char 
emails as ugly and they become a far less effective means of communication than 
other people's emails are, regardless of conscious choice.

It's great if you can choose the people who read your emails, but most of us 
are not so fortunate.

As for standards-compliance, that's a red herring. Long lines are not going to 
trip up any modern client, they're just not.

--
jh...@alum.mit.edu
John Hawkinson

Re: Is linewrap dead?

[Derek Martin]

On Mon, Aug 29, 2022 at 07:10:14AM -0400, John Hawkinson wrote:
> Kurt Hackenberg  wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in 
> :
> 
> > If you put a newline only at the end of a paragraph, it won't be
> > displayed correctly by software that doesn't expect that.  Such
> > software will probably either break each line exactly at the right
> > margin, maybe in the middle of a word, or display a paragraph as a
> > single very long line, maybe with a scroll bar.
> 
> THe point of my statement is to say that this is not a problem in
> practice, no.

I think the fact that we're having this conversation suggests
otherwise...

> But I can confidently say that after years of doing this, omitting
> newlines from internal line breaks in paragraphs has proved to be a
> much better compromise than including them.

I disagree--I find your messages rather hard to read, and beyond that
long paragraphs run the risk of violating SMTP standards.  I can't say
I know how various MTAs handle lines longer than 998 characters, but I
would expect at least a subset would either truncate them or reject
your message... or at least that it would be wise to assume so.

> [ I think, also, that without doing a survey of a wide variety of
> readers, it's tough to appreciate the scope of this problem.

I certainly agree that this is a stupid and annoying problem.

It's been my experience that if you read your mail on anything other
than a phone, the 72-character line width is fine, and even on a phone
if you turn it sideways it's still fine.  My preferred solution, then,
has been to stick with following the standards and assume that if you
insist on reading mail on a hand-held device that can't accommodate
the standard, and/or refuse to rotate it so that it can, then you get
what you get, it's your choice and the consequences of your choice are
on you.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Re: Is linewrap dead?

[Jan Eden via Mutt-users]

On 2022-08-30 14:58, Kurt Hackenberg wrote:

On Tue, Aug 30, 2022 at 09:09:34AM +0200, Jan Eden via Mutt-users wrote:


I would consider f=f an acceptable compromise, because while it looks
nicer on (some) mail clients, it breaks automatic list indentation
created in vim (fo-n). The following is displayed properly in mutt with
linebreaks, but the indentation obviously gets messed up with
text_flowed=yes [mutt] and formatoptions=ntwcql [vim].

1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean
 commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus
 et magnis dis parturient montes, nascetur ridiculus mus.
2. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.
 Nulla consequat massa quis enim. Donec pede justo, fringilla vel,
 aliquet nec, vulputate eget, arcu.


It would get messed up only if spaces were added at the ends of lines. 
Your sample numbered paragraphs above did not have those spaces in 
your message, and don't in this message, even though this message is 
text/plain format=flowed.  The numbered paragraphs should be displayed 
undisturbed.  (This paragraph, however, has those spaces, and should 
be filled and word-wrapped to fit the window width, by any mail reader 
that understands format=flowed.  For example, Mutt with 
reflow_text=yes and reflow_wrap=0.)


Right. I created the numbered paragraphs above without the format=flowed 
support in vim (fo=ntcql), as opposed to the following (fo=nwtcql):


1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean 
   commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus 
   et magnis dis parturient montes, nascetur ridiculus mus.
2. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. 
   Nulla consequat massa quis enim. Donec pede justo, fringilla vel, 
   aliquet nec, vulputate eget, arcu.


I don't use vim, but just tried it a little with formatoptions=aw, and 
textwidth set, so it wrapped automatically.  fo=w tells vim to 
recognize   as a soft line break, but vim didn't 
insert those spaces automatically.  Is there some other option to make 
it insert them?  Or do you have to type them by hand?


vim (9.0) does insert the spaces for me with fo=w (as illustrated in the 
second version of the numbered paragraphs).


- Jan


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[José María Mateos]

On Tue, Aug 30, 2022 at 02:58:38PM -0400, Kurt Hackenberg wrote:
Also, does vim have some option to make whitespace at end of line 
visible, or some other way to show that text is marked as flowed? That 
would be a big help.


I have:

setl list
set listchars=trail:•

This uses a nice fat dot to signal trailing spaces.

Cheers,

--
José María (Chema) Mateos || https://rinzewind.org

Re: Is linewrap dead?

[Kurt Hackenberg]

On Tue, Aug 30, 2022 at 09:09:34AM +0200, Jan Eden via Mutt-users wrote:


I would consider f=f an acceptable compromise, because while it looks
nicer on (some) mail clients, it breaks automatic list indentation
created in vim (fo-n). The following is displayed properly in mutt with
linebreaks, but the indentation obviously gets messed up with
text_flowed=yes [mutt] and formatoptions=ntwcql [vim].

1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean
  commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus
  et magnis dis parturient montes, nascetur ridiculus mus.
2. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.
  Nulla consequat massa quis enim. Donec pede justo, fringilla vel,
  aliquet nec, vulputate eget, arcu.


It would get messed up only if spaces were added at the ends of lines. 
Your sample numbered paragraphs above did not have those spaces in 
your message, and don't in this message, even though this message is 
text/plain format=flowed.  The numbered paragraphs should be displayed 
undisturbed.  (This paragraph, however, has those spaces, and should 
be filled and word-wrapped to fit the window width, by any mail reader 
that understands format=flowed.  For example, Mutt with 
reflow_text=yes and reflow_wrap=0.)


I don't use vim, but just tried it a little with formatoptions=aw, and 
textwidth set, so it wrapped automatically.  fo=w tells vim to 
recognize   as a soft line break, but vim didn't 
insert those spaces automatically.  Is there some other option to make 
it insert them?  Or do you have to type them by hand?


Also, does vim have some option to make whitespace at end of line 
visible, or some other way to show that text is marked as flowed? 
That would be a big help.

Re: Re: Is linewrap dead?

[Jan Eden via Mutt-users]

On 2022-08-29 19:07, Tavis Ormandy wrote:
> On 2022-08-29, Logan Rathbone wrote:
> > On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
> >> No, format=flowed sounds like the perfect solution but I've tested and
> >> as far as I can tell it's ignored by gmail on Android, for example.
> >
> > FWIW, the solution/compromise I ended up using was to compose
> > multipart/alternative mails with mutt, sending a very simple HTML mail
> > and a standard hard-wrapped text-based mail as well. So mobile
> > mailreaders can read it perfectly, and desktop users can read the
> > plaintext version correctly as well.
> >
> 
> Hmm thanks, that does work - I don't like the idea of sending html
> parts, but clearly a compromise is necessary somewhere!

I would consider f=f an acceptable compromise, because while it looks
nicer on (some) mail clients, it breaks automatic list indentation
created in vim (fo-n). The following is displayed properly in mutt with
linebreaks, but the indentation obviously gets messed up with
text_flowed=yes [mutt] and formatoptions=ntwcql [vim].

1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean
   commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus
   et magnis dis parturient montes, nascetur ridiculus mus.
2. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem.
   Nulla consequat massa quis enim. Donec pede justo, fringilla vel,
   aliquet nec, vulputate eget, arcu.

Creating HTML mail with mutt feels more like a surrender. :)

Apart from the known drawbacks of HTML mail, the markdown2html script
has a couple of requirements to further complicate my (already overly
complex) mailstack.

- Jan


signature.asc
Description: PGP signature

Re: Is linewrap dead?

[Kurt Hackenberg]

On 2022/08/29 13:28, Logan Rathbone wrote:


Do phone mail readers understand text/plain format=flowed?


No, format=flowed sounds like the perfect solution but I've tested and
as far as I can tell it's ignored by gmail on Android, for example.


So now we know about Gmail. What about other common mail readers? Does 
something else come with Android? What about the iPhone, and Apple's 
mail reader?


The question is whether smartphone mail readers correctly display 
text/plain format=flowed.

Re: Is linewrap dead?

[Kurt Hackenberg]

On Sun, Aug 28, 2022 at 08:49:50PM -0400, John Hawkinson wrote:

I have not shaken the feeling that maybe I should learn how to 
compose format=flowed messages, but I guess it's not worth the 
trouble -- or at least I never managed to get it to work right.


And yes, I toggle M-x visual-line-mode in Emacs while composing, 
sometimes multiple times, which simulates how the email may be read.


I've made it work with Mutt and Emacs.  How did you add the 
end-of-line spaces?  You can just type them, but that's a lot of 
trouble.

Re: Is linewrap dead?

[Tavis Ormandy]

On 2022-08-29, Logan Rathbone wrote:
> On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
>> No, format=flowed sounds like the perfect solution but I've tested and
>> as far as I can tell it's ignored by gmail on Android, for example.
>
> FWIW, the solution/compromise I ended up using was to compose
> multipart/alternative mails with mutt, sending a very simple HTML mail
> and a standard hard-wrapped text-based mail as well. So mobile
> mailreaders can read it perfectly, and desktop users can read the
> plaintext version correctly as well.
>

Hmm thanks, that does work - I don't like the idea of sending html
parts, but clearly a compromise is necessary somewhere!

I notice the example script shipped with mutt *will* add hard linebreaks
to the html but removing that and it does seem to work (I just added
return mdwn to the top of _preprocess_markdown).

I think either this or the par(1) solution seems to be the best option.

(Or just skip par and do it manually, but I find that jarring after
years of linewrap!)

Tavis.

-- 
 _o)$ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger tav...@sdf.org
_\_V _( ) _( )  @taviso

Re: Is linewrap dead?

[Logan Rathbone]

On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
> On 2022-08-29, Kurt Hackenberg wrote:
> > Maybe text/plain format=flowed is a solution.  It's displayed 
> > correctly by software that assumes format=fixed (on a screen that's 
> > wide enough), and at any width by software that understands 
> > format=flowed.  Mutt can display format=flowed correctly at any width, 
> > if it's configured to.
> >
> > Do phone mail readers understand text/plain format=flowed?
> 
> No, format=flowed sounds like the perfect solution but I've tested and
> as far as I can tell it's ignored by gmail on Android, for example.
 
Correct -- I went through all the rigmarole to set up f=f on Mutt for a
while, and one of the *main reasons* I did so was in the hope that my
mail would display better on mobile mail readers -- which it certainly
did not.

Well, in fairness, it works on FairEmail for instance, but since GMail
for Android is probably one of the most commonly used mailreaders out
there at this point, if it's not supported by that it was kind of
pointless for my use case, for all intents and purposes.

> If we can't even get format=flowed supported, then a new MIME type is
> probably not a workable solution :)
> 
> I think it sounds like turning off linewrap is the only realistic
> solution... [snip]

FWIW, the solution/compromise I ended up using was to compose
multipart/alternative mails with mutt, sending a very simple HTML mail
and a standard hard-wrapped text-based mail as well. So mobile
mailreaders can read it perfectly, and desktop users can read the
plaintext version correctly as well.

Believe it or not, mutt actually has very sophisticated functionality to
achieve this, and even comes with a sample script called markdown2html
to assist with this. I tend to write plaintext mails using a subset of
markdown *anyway*, so it works out very well.

And since sending such mails would obviously annoy certain people (eg,
the users of this ML!) I have mutt set up to prompt if I want to send as
multipart/alternative defaulting to no, as in:

set send_multipart_alternative = ask-no

Re: Is linewrap dead?

[Tavis Ormandy]

On 2022-08-29, Kurt Hackenberg wrote:
> Maybe text/plain format=flowed is a solution.  It's displayed 
> correctly by software that assumes format=fixed (on a screen that's 
> wide enough), and at any width by software that understands 
> format=flowed.  Mutt can display format=flowed correctly at any width, 
> if it's configured to.
>
> Do phone mail readers understand text/plain format=flowed?

No, format=flowed sounds like the perfect solution but I've tested and
as far as I can tell it's ignored by gmail on Android, for example.

If we can't even get format=flowed supported, then a new MIME type is
probably not a workable solution :)

I think it sounds like turning off linewrap is the only realistic
solution... I'm not happy about it, but I think it's time. I heard two
solutions for "fake" wrapping while composing:

1. Write it however you like, just pipe it through par(1) before
   sending. I admit I didn't realize just how powerful par was, this
   could work.

2. Fake it in vim, this is what I currently do. Here is the (hacky)
   solution I was using:

" 998 is the maximum possible line length in SMTP.
" 80 is where you want the fake wrap.
set wiw=80 tw=998
" This forces vim to wrap by creating an empty split.
vnew
wincmd w
" Now there are two windows though, so you need
to use qa instead of q.
cabbrev q =(getcmdtype()==':' &&
getcmdpos()==1 ? 'qa' : 'q')
cabbrev wq =(getcmdtype()==':' &&
getcmdpos()==1 ? 'wqa' : 'wq')

I saw someone else posted a different solution, I'll see if that one
works better.

Tavis.

-- 
 _o)$ lynx lock.cmpxchg8b.com
 /\\  _o)  _o)  $ finger tav...@sdf.org
_\_V _( ) _( )  @taviso

Re: Is linewrap dead?

[José María Mateos]

On Mon, Aug 29, 2022 at 03:43:37PM +0200, Angel M Alganza wrote:

Perhaps if there was a way to configure Mutt to wrap long lines while
reading mail with them and Vim to do the same (visually but not actually
including the new lines) while editing they would be bearable for us who
preffer wrapped mail?


You can do that. For mutt:

unset markers
set wrap = 78

That'll wrap long lines at 78 characters and won't use markers to show 
where a line was wrapped (I found that quite distracting.)


For vim, you can enable soft line wrapping. For example: 
https://vim.works/2019/03/16/wrapping-text-in-vim/


I think this is what you mean in your message, at least. This won't wrap 
any text lines and will leave the client to deal with it as it sees fit. 
On mutt's side, it'll wrap long lines at the 78 char mark.


Cheers,

--
José María (Chema) Mateos || https://rinzewind.org

Re: Is linewrap dead?

[Angel M Alganza]

On Mon, Aug 29, 2022 at 07:10:14AM -0400, John Hawkinson wrote:


omitting newlines from internal line breaks in paragraphs has proved
to be a much better compromise than including them. It displays much
better in a wide array of clients, especially modern ones (webmail
clients, mobile clients), and is not particularly problematic in
classical clients (like mutt).


It's so hard to read and so annoying that I had to split my Notion frame
vertically to be able to read your wole mail.  Also, editing the quotes
is much easier when text is nicely wrapped.


(This email reminds me that a derivative question is how to handle quoted text.


I had to add the > symbols in the previous quote after wrapping it to a
sane width. :-)


Maybe text/plain format=flowed is a solution.  It's displayed correctly by


Maybe.


Perhaps if there was a way to configure Mutt to wrap long lines while
reading mail with them and Vim to do the same (visually but not actually
including the new lines) while editing they would be bearable for us who
preffer wrapped mail?

Cheers,
Ángel

Re: Is linewrap dead?

[John Hawkinson]

Kurt Hackenberg  wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in 
:

> If you put a newline only at the end of a paragraph, it won't be displayed
> correctly by software that doesn't expect that.  Such software will probably
> either break each line exactly at the right margin, maybe in the middle of a
> word, or display a paragraph as a single very long line, maybe with a scroll
> bar.

THe point of my statement is to say that this is not a problem in practice, no.


One of the problems with email is there are so many different clients out there 
that run on so many differnet devices and are configurable in so many different 
ways that it's not possible to make any kind of absolute statement ("this 
always works") beyond statements about standards conformance, which have to be 
tempered with pragmatic reality. And furthermore it's quite different with 
different cultural groups; there are some people ("this business world") that 
only use some kinds of clients, and others (err...the elite hacker world? ha 
ha) who only use some other kinds, and sometimes these groups don't 
intercommunicate enough for there to be an awareness of how the others operate. 
One example of this is the whole "don't top post / replies inline" versus "ONLY 
top-post here!" -type debates, where both sides are entirely ignorant of the 
merits of the other's positions.

But I can confidently say that after years of doing this, omitting newlines 
from internal line breaks in paragraphs has proved to be a much better 
compromise than including them. It displays much better in a wide array of 
clients, especially modern ones (webmail clients, mobile clients), and is not 
particularly problematic in classical clients (like mutt).

[ I think, also, that without doing a survey of a wide variety of readers, it's 
tough to appreciate the scope of this problem. I had NO IDEA how bad my 
hard-wrapped emails used to format for people using clients like Outlook until 
I looked into it explicitly. People just don't tend to talk about things like 
that unless you press them. Although they do make value judgements ("XYZ's 
emails are hard to read.") ]


(This email reminds me that a derivative question is how to handle quoted text. 
I usually continue to wrap quoted text at 72 chars with hard line breaks, as 
I've done in this message. I don't worry too much about quoted text being 
inconveniently formatted in readers that deal with multiple screen sizes, 
although maybe I should.

> One solution would be to invent a new MIME type, say text/paragraph, for

This is obviously a non-starter when the goal is to interoperate with today's 
technology as much as possible.

> Maybe text/plain format=flowed is a solution.  It's displayed correctly by

Maybe.

--
jh...@alum.mit.edu
John Hawkinson


> software that assumes format=fixed (on a screen that's wide enough), and at
> any width by software that understands format=flowed.  Mutt can display
> format=flowed correctly at any width, if it's configured to.
> 
> Do phone mail readers understand text/plain format=flowed?

Re: Is linewrap dead?

[Kurt Hackenberg]

On Mon, Aug 29, 2022 at 12:28:29AM -, Tavis Ormandy wrote:


Hello, long time mutt user here - I've always hard wrapped my lines at
72 columns for as long as I can remember.

The problem is popular modern mobile and web-based MUAs don't handle
this and can make unexpected linewrap decisions. It's no issue when
emailing UNIX nerds, but non-nerds think I'm doing something wrong.

I've seen people convincingly argue it's time to abandon `tw=72` and
never wrap lines manually - newlines are for when you want a new
paragraph.

I've tested, and this does look a lot better on Android for example...
but it just feels and looks wrong! What's the general concensus on this
issue?


Fixed-length lines of 72 characters don't fit on a phone screen 
smaller than that.  You could break lines at the exact width of a 
particular recipient's phone screen...(no, I'm not serious).


If you put a newline only at the end of a paragraph, it won't be 
displayed correctly by software that doesn't expect that.  Such 
software will probably either break each line exactly at the right 
margin, maybe in the middle of a word, or display a paragraph as a 
single very long line, maybe with a scroll bar.


The problem is, plain text and paragraph text are two different ways 
to interpret a sequence of characters, and it's hard for software to 
know which the sender intended.


One solution would be to invent a new MIME type, say text/paragraph, 
for text that has a newline only at the end of a paragraph, and so 
should be automatically filled and word-wrapped to fit the screen. 
Apparently some such MIME type was considered in the past, but 
rejected (RFC 3676 mentions it).


Maybe text/plain format=flowed is a solution.  It's displayed 
correctly by software that assumes format=fixed (on a screen that's 
wide enough), and at any width by software that understands 
format=flowed.  Mutt can display format=flowed correctly at any width, 
if it's configured to.


Do phone mail readers understand text/plain format=flowed?

Re: Is linewrap dead?

[John Hawkinson]

I gave up on linewrapping emails I transmit several years ago for the reasons 
you describe, and it has been the right decision.

I have not shaken the feeling that maybe I should learn how to compose 
format=flowed messages, but I guess it's not worth the trouble -- or at least I 
never managed to get it to work right.

And yes, I toggle M-x visual-line-mode in Emacs while composing, sometimes 
multiple times, which simulates how the email may be read.

--
jh...@alum.mit.edu
John Hawkinson


Tavis Ormandy  wrote on Sun, 28 Aug 2022
at 20:28:29 EDT in :

> Hello, long time mutt user here - I've always hard wrapped my lines at
> 72 columns for as long as I can remember.
> 
> The problem is popular modern mobile and web-based MUAs don't handle
> this and can make unexpected linewrap decisions. It's no issue when
> emailing UNIX nerds, but non-nerds think I'm doing something wrong.
> 
> I've seen people convincingly argue it's time to abandon `tw=72` and
> never wrap lines manually - newlines are for when you want a new
> paragraph.
> 
> I've tested, and this does look a lot better on Android for example...
> but it just feels and looks wrong! What's the general concensus on this
> issue?
> 
> I find it so weird for my lines not to soft-wrap in a big xterm that
> I had to make a vim macro to "fake" wrap them while composing :)