GNU bug report logs - #71017
fill-flowed-encode

Previous Next

Full log

View this message in rfc822 format

From: Sandra Snan <sandra.snan <at> idiomdrottning.org>
To: Henrik Ahlgren <pablo <at> seestieto.com>
Cc: 71017 <at> debbugs.gnu.org
Subject: bug#71017: fill-flowed-encode
Date: Thu, 13 Mar 2025 12:41:53 +0100

Even though my setup works well with this "harden-region" stuff 
(and I keep double-checking how what I send from Emacs look in 
e.g. Delta Chat), I've been thinking that maybe this entire 
hard/soft newlines as invisibly delineated by props might 
fundamentally not be the best approach. Let's call it "approach 
one". This is what I'm still currently working for email and I 
haven't had any mishaps in a while thanks my patched 
messages-are-flowing. I hacked it so that newlines that are 
paragraph breaks do NOT show those annoying li'l return signs, 
but hard newlines that are in the middle of a paragraph (for code 
or poetry) do show them. That was very scary to deploy (as hiding 
information from myself always is) but it has been working.

Now, for all three approaches, I'm talking about the local 
writing format in the buffer for the Emacs user. The wire format 
shall the same for all three approaches i.e. the current approach 
which follows the RFC without stuffing > marks. 
https://idiomdrottning.org/format-flowed

One idea, "approach two", might be to use an idea from markdown: 
Paragraphs (i.e. \n\n+) are always hard, lines that start with 
four spaces or end with two spaces have those spaces removed and 
are also made hard, and all other newlines are soft. With 
approach two you still need to remember to add spaces to code 
sections (for example with markdown-pre-region) so it keeps some 
of the same "harden-region" problem of the approach one. This 
approach two is what I am and have been using for many years to 
write for my blog. I personally only ever use the four spaces 
with markdown-pre-region rather than the three backtick "code 
fence" method but if we were to go with approach two, we'd 
probably better support both.

And then "approach three" would be... All newlines are hard. I've 
been using approach three to post on Fediverse and I've been 
using visual-fill-column-mode together with some hooks that make 
it and visual-line-mode toggle in lockstep so there's never one 
without the other. I need to remember to have autofill *off* when 
using this, but it's been so great! I know, I know, this is a 
very "Windows and Mac" approach to text (and don't worry, the 
wire format will still be wrapped using the flowed RFC, we're not 
actually *sending* these hyper long lines here) but it works. 
I've always thought visual-line-mode was completely useless and 
ugly but with visual-fill-column-mode it works really well. It's 
not as fire-and-forget as the other two approaches since the one 
drawback to approach three is that if I'm not sure I accidentally 
made a newline, I won't see it. So when that creeping insecurity 
starts rearing, I toggle visual-line-mode (which also toggles 
visual-fill-column-mode) to double check. Or if it's just one 
line I can delete the "is it a space or a newline" character and 
insert a space, but, I'm more likely to do the toggle check since 
I have it on the keymap & on the mode line.

So, hmm, all three approaches have their drawbacks. The first two 
requires deliberately hardening and softening, the third matches 
many other modern apps but can (rarely) accidentally insert stray 
hards. A harder-to-detect but less-catastrophic error than 
accidentally softening a huge code patch or poem.

So what do y'all think, keep on polishing the first approach or 
switch to two or three (and maybe polish them further)? For me 
this itch has been well scratched with my patches both here and 
to messages-are-flowing ( 
https://github.com/legoscia/messages-are-flowing/pull/15/ ). 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.