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

Previous Next

Full log

Message #20 received at 71017 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sandra Snan <sandra.snan <at> idiomdrottning.org>,
 Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 71017 <at> debbugs.gnu.org
Subject: Re: bug#71017: [PATCH] Flow single-paragraph messages
Date: Sun, 07 Jul 2024 08:43:57 +0300

> Cc: Sandra Snan <sandra.snan <at> idiomdrottning.org>
> Date: Sat,  6 Jul 2024 22:49:50 +0200
> From:  Sandra Snan via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> This fixes two bugs when sending RFC 2646–formatted email.

Thanks.  (I also see RFC 3676 mentioned -- what is this about?)

> First, the old code didn't refill or encode the last paragraph at all
> unless there was at least one hard newline EOF.

Isn't this the documented behavior?

> But for months dogfooding those two changes, sometimes a hardwrapped
> email would still be sent. I finally managed to debug and figure it out
> and it took all day. Turns out mml just plain didn't call the
> fill-flowed-encode function if the message doesn't have any hard
> newlines (newlines with the hard text property). Well, of course a
> single-paragraph email isn't gonna have any hard newlines! But it still
> needs reflowing!
> 
> So I've now changed that and updated the documentation to match those
> news semantics. I went all the way, but a possible compromise might be
> to not-flow a message that has \n\n but no hard text props, since that's
> a sign that something is wrong.

The change seems to be an incompatible behavior change, so I wonder
whether we'd need some way for users to get back old behavior.  Eric,
WDYT?

I'll leave it to Eric to comment on the code changes.

Previous Next

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