Hi all!
RFC 3676, which defines Format=Flowed, also sets some requirements for
message quoting. Apart from mandating the ">" character, it also
formalizes the concept of "quote depth". The standards says that "The
number of ">" characters at the start of the line specifies the quote
depth", and it really means it; the examples make it clearer:
When creating quoted flowed lines, each such line starts with the
quote indicator.
Note that because of space-stuffing, the lines
>> Exit, Stage Left
and
>>Exit, Stage Left
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".
However, the line
> > Exit, Stage Left
is different. It has a quote-depth of one, and a content of
"> Exit, Stage Left".
Aerc's default quoting stile, however, prepends "> " to quoted parts
unconditionally, even when the compose.format-flowed option is enabled.
To make aerc conform to the RFC, it would have to prepend messages with
">" if the first character of the line is another ">", and prepend lines
with "> " otherwise.
What about adding a new "quoteFF" template function (better names
welcome) which implements RFC 3676-compliant quoting?
Bye :)
On Sun Jul 7, 2024 at 10:17 AM CEST, Andrea Pappacoda wrote:
> RFC 3676, which defines Format=Flowed, also sets some requirements for > message quoting. Apart from mandating the ">" character, it also > formalizes the concept of "quote depth". The standards says that "The > number of ">" characters at the start of the line specifies the quote > depth", and it really means it; the examples make it clearer:
format=flowed emails is another of those things which I would
love if worked, but they don’t (besides, it doesn’t resolve
issues, which I see as actual problems … e.g., an inclusion of
too long URLs in emails, hand-made footnotes I make here are not
ideal).
A lot of arugments why I think it is a waste of time to even try
to implement are covered in [1] (many implementations are also
buggy [2]), but paradoxically even people who claim to support it
break it openly [3] (no, that isn’t improving of the format, it
is giving up, RFC3676 email should have 78 characters per line,
maximum, adding otherwise non-sensical "format=flowed" text to
Content-Type header is misleading).
I was very much concerned about that “Don’t send patches with
`format=flowed`.” [4], but more I think about it more it seems
irrelevant. After all, one should never use your regular MUA for
sending patches, it should be done by git send-email [5] only
anyway, and normal MUA is used for the review about the patches
and conversation about it. So, perhaps the broken support for
format=flowed in Thunderbird [6] is actually a good thing?
Generally, it seems to me that whole thing has more problems
than it is worth, and limited support for HTML (e.g., what aerc
does with w3m filtering) is probably the best thing we can hope
for. Not sure about the authoring such emails (writing them in
Markdown and filtering on sending?).
Best,
Matěj
[1] https://www.fastmail.com/blog/format-flowed/
[2] https://www.firstpr.com.au/web-mail/Mozilla-mail/ (and
23-years and 22-years old https://bugzilla.mozilla.org/88986
and https://bugzilla.mozilla.org/168420)
[3] https://vxlabs.com/2019/08/25/format-flowed-with-long-lines/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/email-clients.rst
[5] https://git-send-email.io/
[6] https://cpbotha.net/2016/09/27/thunderbird-support-of-rfc-3676-formatflowed-is-half-broken/
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Why should I travel, when I’m already there?
-- Bostonian lady, when being asked why she never visited
other places than Boston
Hi Matěj,
On Sun Jul 7, 2024 at 9:07 PM CEST, Matěj Cepl wrote:
> format=flowed emails is another of those things which I would> love if worked, but they don’t (besides, it doesn’t resolve> issues, which I see as actual problems … e.g., an inclusion of> too long URLs in emails, hand-made footnotes I make here are not> ideal).>> A lot of arugments why I think it is a waste of time to even try> to implement are covered in [1] (many implementations are also> buggy [2]), but paradoxically even people who claim to support it> break it openly [3] (no, that isn’t improving of the format, it> is giving up, RFC3676 email should have 78 characters per line,> maximum, adding otherwise non-sensical "format=flowed" text to> Content-Type header is misleading).>> I was very much concerned about that “Don’t send patches with> `format=flowed`.” [4], but more I think about it more it seems> irrelevant. After all, one should never use your regular MUA for> sending patches, it should be done by git send-email [5] only> anyway, and normal MUA is used for the review about the patches> and conversation about it. So, perhaps the broken support for> format=flowed in Thunderbird [6] is actually a good thing?>> Generally, it seems to me that whole thing has more problems> than it is worth, and limited support for HTML (e.g., what aerc> does with w3m filtering) is probably the best thing we can hope> for. Not sure about the authoring such emails (writing them in> Markdown and filtering on sending?).>> Best,>> Matěj>> [1] https://www.fastmail.com/blog/format-flowed/> [2] https://www.firstpr.com.au/web-mail/Mozilla-mail/ (and> 23-years and 22-years old https://bugzilla.mozilla.org/88986> and https://bugzilla.mozilla.org/168420)> [3] https://vxlabs.com/2019/08/25/format-flowed-with-long-lines/> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/email-clients.rst> [5] https://git-send-email.io/> [6] https://cpbotha.net/2016/09/27/thunderbird-support-of-rfc-3676-formatflowed-is-half-broken/
Thank you for presenting your concerns about format=flowed. While
I agree that the current situation is not ideal, I also have to say that
there's also some good about it. For instance, flowed emails are the
only kind of plain text emails which look great on both my mobile email
client, K-9 Mail, and my desktop client, aerc.
Sure, HTML emails can sometimes look better, but I don't want to send,
nor receive, HTML emails when plain text would suffice. There's a reason
why we have <https://useplaintext.email> ;)
Also, I find that some arguments used by Fastmail are either invalid or
don't apply to aerc: not implementing something because others haven't
either isn't by itself a good argument in my opinion, and the other
reasons cited by them are related to flowed rendering and composing,
which aerc doesn't have to support (and Vim can reformat flowed quoted
parts just fine).
Really, the biggest issue about format=flowed is that not many email
clients fully support it. There's nothing wrong in supporting the format
itself; it can only make things better, actually! (e.g. mobile clients
rendering)
Unless I'm missing something, the only parts of RFC 3676 which should be
implemented by aerc should be fairly simple - everything that has to do
with rendering can be ignored, and message composition is up to the
underlying editor. I may look into hacking into the codebase myself (if
there is no opposition in merging such a patch, of course!).
Bye :)
Andrea Pappacoda, Jul 07, 2024 at 21:54:
> Unless I'm missing something, the only parts of RFC 3676 which should be > implemented by aerc should be fairly simple - everything that has to do > with rendering can be ignored, and message composition is up to the > underlying editor. I may look into hacking into the codebase myself (if > there is no opposition in merging such a patch, of course!).
Hey Andrea,
All the rendering part is already handled by the builtin wrap filter:
https://git.sr.ht/~rjarry/aerc/tree/master/item/filters/wrap.c
The only thing missing would be the that the quote filter should omit
the space between the angle bracket prefix and the quoted text itself
when [compose].format-flowed=true.
This should be fairly easy to do. The only minor inconvenience is that
lib/templates is already imported by the config package. This prevents
lib/templates from accessing the config objects via imports. We will
need another way to pass down the info.
On Sun Jul 7, 2024 at 9:54 PM CEST, Andrea Pappacoda wrote:
> Sure, HTML emails can sometimes look better, but I don't want to send, > nor receive, HTML emails when plain text would suffice. There's a reason > why we have <https://useplaintext.email> ;)
Except RFC3676 is not plain text any more, but rather not very
well designed formar with too strict definition. For example, I
hold that not accepting '> > ' as a quote mark is just a bug, and
most people I see doing quoting put space in between those '>'
signs. If you reject that, you are breaking Postel Law and making
your format too strict to use naturally.
Email is primarily tool for communication, and using formats
which are not widely used (also text/enriched, which is even
more dead than dead and solving even less actual problems)
goes against whole sense of the thing. Yes, format=flowed
doesn’t break on that many clients that much, but why to use it
when the same thing can be achieved using HTML mail, and with
multipart converters (see aerc-config(5)) you can author very
simple non-offensive HTML very easily, and you are automatically
compatible with everybody.
Best,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
The American Republic will endure, until politicians realize they
can bribe the people with their own money.
-- based on a statement of Alexander Fraser Tytler