Emacs RFC 2646 email flowing
Heck it Emacs!
A few months ago I fixed a bug in RFC 2646 handling where the last paragraph wouldn’t get reflowed unless I remembered to add a hard newline (that is, a newline with the 'hard text property) *after* it, at EOT. I needed to hit one extra RET at the end. All other paragraphs would be wrapped, not just the last one.
(I even bugged @jas about it.)
But it still didn’t always work and today I tried to get to the bottom of why, spending the entire day debugging it, finally realizing that… It’s not even being *called* when there’s only one paragraph in the email. I wasted so much time before realizing that! And then getting to the bottom of why *that* wasn’t happening was the opposite of easy but it turnes out that Gnus by design doesn’t call the fill-flowed-encode function when there aren’t any hard newlines in the buffer. Which there aren’t gonna be if it’s a single-paragraph letter 🤦🏻♀️
Use-hard-newlines is beyond useless since that’s always buffer-local and the text-reflowing is being done in a temp buffer. Instead since 2010 we’re supposed to set mml-enable-flowed to true. But don’t worry, fans of the messages-are-flowing package, I’m gonna send patches there to reflect that. I have a bunch of other changes to that package too since I’ve been using that a lot this summer.
This is all in bug#71017 (cursed palindrome!) for people who wanna dig in 👩🏻🏫
As I noted in my patch message and in the previous post, behavior gets a li’l weird when someone leaves
mml-enable-flowedon (the default!) but forgets to turn onuse-hard-newlines(not the default! And since it’s buffer local, it needs to be turned on every single time, for example with a hook).So with these two settings kept at their defaults, separate paragraphs will get flowed together with my patch! So I sent a new version of the patch to the same #71017 thread that’ll auto-harden according to markdown semantics as a dwimmy fallback.