Re: `hard-newline' changes trigger format=flowed in Gnus

[David Koppelman]

Reiner Steib <address@hidden> writes:

> There is some information in emacs-mime.texi:
>
> ,----[ (info "(emacs-mime)Flowed text") ]
> | The Emacs MIME library will respect the `use-hard-newlines' variable
> | (*note Hard and Soft Newlines: (emacs)Hard and Soft Newlines.) when
> | encoding a message, and the "format=flowed" Content-Type parameter when
> | decoding a message.
> | 
> |    On encoding text, regardless of `use-hard-newlines', lines
> | terminated by soft newline characters are filled together and wrapped
> | after the column decided by `fill-flowed-encode-column'.  Quotation
> | marks (matching `^>* ?') are respected.  The variable controls how the
> | text will look in a client that does not support flowed text, the
> | default is to wrap after 66 characters.  If hard newline characters are
> | not present in the buffer, no flow encoding occurs.
> | [...]
> `----
>
> IMHO, it won't hurt to add a short note and reference to this
> explanation in gnus.texi and message.texi.  The only occurrence is in
> the "New Features" section (info "(gnus)Oort Gnus").  Suggestions?

If I understand things correctly if soft and hard newline characters
are found then it will be assumed that a soft newline is what was
intended and so text will be flowed, no questions asked. But there are
many cases in which the soft newline character is there by
"accident". The sender won't know until the recipient gets back to the
sender and then the sender will have to delve deeply into lisp or the
documentation to diagnose the problem and develop a workaround.

Therefore one must be much more careful before flowing. Perhaps some
combination of the following:

 Some indication that text will be assumed flowable, perhaps in the
 modeline or perhaps by highlighting around the soft newlines.

 If flowability has been assumed then ask the user if that's correct and
 take yes, yes always, no, and no never responses.