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.
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-flowed on (the default!) but forgets to turn on use-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.