GNU logs - #71017, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71017: fill-flowed-encode
Resent-From: Sandra Snan <sandra.snan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 17 May 2024 20:25:02 +0000
Resent-Message-ID: <handler.71017.B.17159774433558 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 71017 <at> debbugs.gnu.org
From: Sandra Snan <sandra.snan@HIDDEN>
Autocrypt: addr=sandra.snan@HIDDEN; prefer-encrypt=mutual; keydata=
 mDMEZWEIEhYJKwYBBAHaRw8BAQdAahVPtpoqkiV62AL3GSY4JaPS0i3Bu3fhbe5WIFQG9pa0LFNh
 bmRyYSBTbmFuIDxzYW5kcmEuc25hbkBpZGlvbWRyb3R0bmluZy5vcmc+iJMEExYIADsCGwMFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AWIQSM+QwgZjV9IBEt0Difw0TKEvFISgUCZWJbSgIZAQAKCRCf
 w0TKEvFIShsYAPsFMXn+tFcAwdI2hrkqqQY8I5EC9UWYC9t57VjiYv2uYQD+PUNVHVSBGQDycf3V
 /nXqXvZvTfcFMOz0PVMzibPl0AiIkAQTFggAOBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgS
 AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJ/DRMoS8UhK07EA/iV2B5e3r8t8/StJT38d
 x9YbuoSBmbYZJ6JHH9hoyv0hAPwMiH1M8zZUeQK/TQDqkg2Hjk0xL+U7i9ggocLJEAWQDbg4BGVh
 CBISCisGAQQBl1UBBQEBB0BqHjRRmoXeZmeeUZOqL1ebAflzYFA3jHwxl2sLMLlMCgMBCAeIeAQY
 FggAIBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgSAhsMAAoJEJ/DRMoS8UhK4o0BAOB7ChkN
 Jc0oxRDg9WvrbUCnpLU/QdjMFcC8ymLRdzxaAP4gZVL0JQfxulc/JAxotCevk1PAF+UXpY8QalTI
 dooaAA==
Date: Fri, 17 May 2024 22:23:50 +0200
Message-ID: <87v83cfaqx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2600:3c02:e000:179::7;
 envelope-from=sandra.snan@HIDDEN; helo=halsen.idiomdrottning.org
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hi y'all.

flow-fill.el.gz has a pair of functions, fill-flowed-encode and=20
fill-flowed-fill-buffer (the latter is only called from the=20
former).

Here is a fixed version of the former that then also deprecates=20
the latter (I have signed FSF copyright papers):

(defun fill-flowed-encode (&optional buffer)
  (with-current-buffer (or buffer (current-buffer))
    ;; No point in doing this unless hard newlines is used.
    (when use-hard-newlines
      (let ((start (point-min)) end)
	;; Go through each paragraph, filling it and adding SPC
	;; as the last character on each line.
	(while (and (< start (point-max))
		    (setq end (or (text-property-any start (point-max) 'hard 't)
				  (point-max))))
	  (save-restriction
	    (narrow-to-region start end)
	    (let ((fill-column (eval fill-flowed-encode-column t))
		  (prefix
		   (concat "\n"
			   (or (and (looking-at ">[> ]*")
				    (match-string 0)) ""))))
	      (while (search-forward prefix nil t)
		(replace-match " " t t))
	      (goto-char start)
	      (while (< (+ (point) fill-column) (point-max))
		(forward-char fill-column)
		(search-backward " ")
		(forward-char)
		(insert prefix)))
	    (setq start (1+ (point-max))))))
      t)))

This fixes two bugs when sending RFC 2646=E2=80=93formatted email.

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

Second, the old code borked up code indented with tabs and spaces=20
(iff that code had overly long lines), such as the Lisp code in=20
this email. It could sometimes insert extra in the middle of such=20
long lines.

Here is an example of what it would do. It would turn this:

(defun lorem (ipsum)
  (dolor sit amet)
  (consectetur adipiscing elit (sed do eiusmod tempor incididunt=20
ut labore et dolore magna aliqua))
  (ut enim ad minim veniam
      (quis nostrud exercitation ullamco laboris nisi ut aliquip=20
ex ea commodo consequat
	    (duis aute irure dolor in reprehenderit in
		  voluptate velit esse cillum dolore
		  eu fugiat nulla pariatur)
	    excepteur sint occaecat cupidatat non proident
	    (sunt in culpa qui officia deserunt mollit anim id est=20
laborumd))))

into this:

(defun lorem (ipsum)
  (dolor sit amet)
  (consectetur adipiscing elit (sed do eiusmod tempor incididunt
  ut labore et dolore magna aliqua))
  (ut enim ad minim veniam
      (quis nostrud exercitation ullamco laboris nisi ut aliquip
      ex ea commodo consequat
	    (duis aute irure dolor in reprehenderit in
		  voluptate velit esse cillum dolore
		  eu fugiat nulla pariatur)
	    excepteur sint occaecat cupidatat non proident
	    (sunt in culpa qui officia deserunt mollit anim id est
	    laborumd))))

It was breaking lines awkwardly so when they're reconnected they=20
have extra whitespace in the mkddle of lines.=20

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Sandra Snan <sandra.snan@HIDDEN>
Subject: bug#71017: Acknowledgement (fill-flowed-encode)
Message-ID: <handler.71017.B.17159774433558.ack <at> debbugs.gnu.org>
References: <87v83cfaqx.fsf@HIDDEN>
X-Gnu-PR-Message: ack 71017
X-Gnu-PR-Package: emacs
Reply-To: 71017 <at> debbugs.gnu.org
Date: Fri, 17 May 2024 20:25:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 71017 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
71017: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D71017
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71017: fill-flowed-encode
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Jun 2024 05:46:02 +0000
Resent-Message-ID: <handler.71017.B71017.171972631819383 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Sandra Snan <sandra.snan@HIDDEN>
Cc: 71017 <at> debbugs.gnu.org
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <87v83cfaqx.fsf@HIDDEN> (Sandra Snan's message
 of "Fri, 17 May 2024 22:23:50 +0200")
References: <87v83cfaqx.fsf@HIDDEN>
MIME-Version: 1.0
Date: Sat, 29 Jun 2024 22:44:09 -0700
Message-ID: <CADwFkm=fhoQGLgEHv6XsDPTzyeJBO+--krz+4RkoBoLjtGg1bQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Sandra Snan <sandra.snan@HIDDEN> writes:

> Hi y'all.

Hi Sandra,

> flow-fill.el.gz has a pair of functions, fill-flowed-encode and
> fill-flowed-fill-buffer (the latter is only called from the former).
>
> Here is a fixed version of the former that then also deprecates the latte=
r (I
> have signed FSF copyright papers):
>
> (defun fill-flowed-encode (&optional buffer)
>  (with-current-buffer (or buffer (current-buffer))
>    ;; No point in doing this unless hard newlines is used.
>    (when use-hard-newlines
>      (let ((start (point-min)) end)
> 	;; Go through each paragraph, filling it and adding SPC
> 	;; as the last character on each line.
> 	(while (and (< start (point-max))
> 		    (setq end (or (text-property-any start (point-max) 'hard 't)
> 				  (point-max))))
> 	  (save-restriction
> 	    (narrow-to-region start end)
> 	    (let ((fill-column (eval fill-flowed-encode-column t))
> 		  (prefix
> 		   (concat "\n"
> 			   (or (and (looking-at ">[> ]*")
> 				    (match-string 0)) ""))))
> 	      (while (search-forward prefix nil t)
> 		(replace-match " " t t))
> 	      (goto-char start)
> 	      (while (< (+ (point) fill-column) (point-max))
> 		(forward-char fill-column)
> 		(search-backward " ")
> 		(forward-char)
> 		(insert prefix)))
> 	    (setq start (1+ (point-max))))))
>      t)))
>
> This fixes two bugs when sending RFC 2646=E2=80=93formatted email.
>
> First, the old code didn't refill or encode the last paragraph at all unl=
ess
> there was at least one hard newline EOF.
>
> Second, the old code borked up code indented with tabs and spaces (iff th=
at code
> had overly long lines), such as the Lisp code in this email. It could som=
etimes
> insert extra in the middle of such long lines.
>
> Here is an example of what it would do. It would turn this:
>
> (defun lorem (ipsum)
>  (dolor sit amet)
>  (consectetur adipiscing elit (sed do eiusmod tempor incididunt ut labore=
 et
> dolore magna aliqua))
>  (ut enim ad minim veniam
>      (quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea com=
modo
>     consequat
> 	    (duis aute irure dolor in reprehenderit in
> 		  voluptate velit esse cillum dolore
> 		  eu fugiat nulla pariatur)
> 	    excepteur sint occaecat cupidatat non proident
> 	    (sunt in culpa qui officia deserunt mollit anim id est laborumd))))
>
> into this:
>
> (defun lorem (ipsum)
>  (dolor sit amet)
>  (consectetur adipiscing elit (sed do eiusmod tempor incididunt
>  ut labore et dolore magna aliqua))
>  (ut enim ad minim veniam
>      (quis nostrud exercitation ullamco laboris nisi ut aliquip
>      ex ea commodo consequat
> 	    (duis aute irure dolor in reprehenderit in
> 		  voluptate velit esse cillum dolore
> 		  eu fugiat nulla pariatur)
> 	    excepteur sint occaecat cupidatat non proident
> 	    (sunt in culpa qui officia deserunt mollit anim id est
> 	    laborumd))))
>
> It was breaking lines awkwardly so when they're reconnected they have ext=
ra
> whitespace in the mkddle of lines.

Could you please resend the above as patches formatted by

    git format-patch -1

?

It will make it easier for us to review and install the proposed
changes.  Thanks in advance.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#71017: fill-flowed-encode
Resent-From: Sandra Snan <sandra.snan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Jun 2024 08:33:01 +0000
Resent-Message-ID: <handler.71017.B71017.17197363613149 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: 71017 <at> debbugs.gnu.org
From: Sandra Snan <sandra.snan@HIDDEN>
In-Reply-To: <CADwFkm=fhoQGLgEHv6XsDPTzyeJBO+--krz+4RkoBoLjtGg1bQ@HIDDEN>
References: <87v83cfaqx.fsf@HIDDEN>
 <CADwFkm=fhoQGLgEHv6XsDPTzyeJBO+--krz+4RkoBoLjtGg1bQ@HIDDEN>
Autocrypt: addr=sandra.snan@HIDDEN; prefer-encrypt=mutual; keydata=
 mDMEZWEIEhYJKwYBBAHaRw8BAQdAahVPtpoqkiV62AL3GSY4JaPS0i3Bu3fhbe5WIFQG9pa0LFNh
 bmRyYSBTbmFuIDxzYW5kcmEuc25hbkBpZGlvbWRyb3R0bmluZy5vcmc+iJMEExYIADsCGwMFCwkI
 BwIGFQoJCAsCBBYCAwECHgECF4AWIQSM+QwgZjV9IBEt0Difw0TKEvFISgUCZWJbSgIZAQAKCRCf
 w0TKEvFIShsYAPsFMXn+tFcAwdI2hrkqqQY8I5EC9UWYC9t57VjiYv2uYQD+PUNVHVSBGQDycf3V
 /nXqXvZvTfcFMOz0PVMzibPl0AiIkAQTFggAOBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgS
 AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJ/DRMoS8UhK07EA/iV2B5e3r8t8/StJT38d
 x9YbuoSBmbYZJ6JHH9hoyv0hAPwMiH1M8zZUeQK/TQDqkg2Hjk0xL+U7i9ggocLJEAWQDbg4BGVh
 CBISCisGAQQBl1UBBQEBB0BqHjRRmoXeZmeeUZOqL1ebAflzYFA3jHwxl2sLMLlMCgMBCAeIeAQY
 FggAIBYhBIz5DCBmNX0gES3QOJ/DRMoS8UhKBQJlYQgSAhsMAAoJEJ/DRMoS8UhK4o0BAOB7ChkN
 Jc0oxRDg9WvrbUCnpLU/QdjMFcC8ymLRdzxaAP4gZVL0JQfxulc/JAxotCevk1PAF+UXpY8QalTI
 dooaAA==
Date: Sun, 30 Jun 2024 10:32:34 +0200
Message-ID: <871q4ej0f1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Stefan Kangas <stefankangas@HIDDEN> writes:

> Could you please resend the above as patches formatted by
>
>     git format-patch -1
>
> ?
>

I'm glad I'm gonna get a chance to resend because I've fixed some=20
more bugs in the version I've been dogfooding since I first sent=20
that so I wanna send an updated version that has that.

Normally when I'm sending Emacs lisp patches, it's on packages and=20
they're usually in git already. Here it's a core file so the=20
question I've got is what is the git repo I should make the change=20
in? Then I could git send-email to this In-Reply-To thread id.

Stefan Kangas <stefankangas@HIDDEN> writes:

> Sandra Snan <sandra.snan@HIDDEN> writes:
>
>> Hi y'all.
>
> Hi Sandra,
>
>> flow-fill.el.gz has a pair of functions, fill-flowed-encode and=20
>> fill-flowed-fill-buffer (the latter is only called from the=20
>> former).
>> Here is a fixed version of the former that then also=20
>> deprecates the latter (I have signed FSF copyright papers):
>>=20
>> (defun fill-flowed-encode (&optional buffer)  (with-current-buffer=20
>> (or buffer (current-buffer))    ;; No point in doing this unless=20
>> hard newlines is used.    (when use-hard-newlines      (let ((start=20
>> (point-min)) end) 	;; Go through each paragraph, filling it and=20
>> adding SPC 	;; as the last character on each line. 	(while (and (<=20
>> start (point-max)) 		    (setq end (or (text-property-any start=20
>> (point-max) 'hard 't) 				  (point-max)))) 	  (save-restriction=20=09=20=
=20=20
>>  (narrow-to-region start end) 	    (let ((fill-column (eval=20
>> fill-flowed-encode-column t)) 		  (prefix 		   (concat "\n"=20=09=09=09=
=20=20=20
>> (or (and (looking-at ">[> ]*") 				    (match-string 0)) ""))))=20=09=20=
=20=20
>>    (while (search-forward prefix nil t) 		(replace-match " " t t))=20
>> 	      (goto-char start) 	      (while (< (+ (point) fill-column)=20
>> (point-max)) 		(forward-char fill-column) 		(search-backward " ")=20
>> 		(forward-char) 		(insert prefix))) 	    (setq start (1+=20
>> (point-max))))))      t)))
>> This fixes two bugs when sending RFC=20
>> 2646=E2=80=93formatted email.
>> First, the old code didn't refill or=20
>> encode the last paragraph at all unless there was at least one hard=20
>> newline EOF.
>> Second, the old code borked up code indented with=20
>> tabs and spaces (iff that code had overly long lines), such as the=20
>> Lisp code in this email. It could sometimes insert extra in the=20
>> middle of such long lines.
>> Here is an example of what it would=20
>> do. It would turn this:
>> (defun lorem (ipsum)  (dolor sit amet)=20=20
>> (consectetur adipiscing elit (sed do eiusmod tempor incididunt ut=20
>> labore et dolore magna aliqua))  (ut enim ad minim veniam=20=20=20=20=20=
=20
>> (quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea=20
>> commodo     consequat 	    (duis aute irure dolor in reprehenderit=20
>> in 		  voluptate velit esse cillum dolore 		  eu fugiat nulla=20
>> pariatur) 	    excepteur sint occaecat cupidatat non proident=20=09=20=
=20=20=20
>> (sunt in culpa qui officia deserunt mollit anim id est=20
>> laborumd))))
>> into this:
>> (defun lorem (ipsum)  (dolor sit=20
>> amet)  (consectetur adipiscing elit (sed do eiusmod tempor=20
>> incididunt  ut labore et dolore magna aliqua))  (ut enim ad minim=20
>> veniam      (quis nostrud exercitation ullamco laboris nisi ut=20
>> aliquip      ex ea commodo consequat 	    (duis aute irure dolor in=20
>> reprehenderit in 		  voluptate velit esse cillum dolore 		  eu=20
>> fugiat nulla pariatur) 	    excepteur sint occaecat cupidatat non=20
>> proident 	    (sunt in culpa qui officia deserunt mollit anim id=20
>> est 	    laborumd))))
>> It was breaking lines awkwardly so when=20
>> they're reconnected they have extra whitespace in the mkddle of=20
>> lines.
>
> Could you please resend the above as patches formatted by
>
>     git format-patch -1
>
> ?
>
> It will make it easier for us to review and install the proposed=20
> changes.  Thanks in advance.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71017: fill-flowed-encode
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Jun 2024 14:36:02 +0000
Resent-Message-ID: <handler.71017.B71017.171975812623207 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71017
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Sandra Snan <sandra.snan@HIDDEN>
Cc: 71017 <at> debbugs.gnu.org
Received: via spool by 71017-submit <at> debbugs.gnu.org id=B71017.171975812623207
          (code B ref 71017); Sun, 30 Jun 2024 14:36:02 +0000
Received: (at 71017) by debbugs.gnu.org; 30 Jun 2024 14:35:26 +0000
Received: from localhost ([127.0.0.1]:58632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sNveH-00062F-HV
	for submit <at> debbugs.gnu.org; Sun, 30 Jun 2024 10:35:25 -0400
Received: from mail-ed1-f49.google.com ([209.85.208.49]:56580)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1sNveF-000627-OG
 for 71017 <at> debbugs.gnu.org; Sun, 30 Jun 2024 10:35:24 -0400
Received: by mail-ed1-f49.google.com with SMTP id
 4fb4d7f45d1cf-57cd26347d3so2651318a12.1
 for <71017 <at> debbugs.gnu.org>; Sun, 30 Jun 2024 07:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719758063; x=1720362863; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=tW0tsHROR4p5YLwOqk8xa2rUpWs/nOmcbPjxjCZxRFM=;
 b=AwJCFnZsxY7tiQ9HK+0wC8XB0RSvwVct/tsWJK0SGtAw4xM4gy8oLjRH4q1kk7PxHZ
 DzsIqKIppFkFWyl2h/Nl+cVERFQwCThOAsOfCzEBw5RRx2lHA7mNstEILW7miHxrQW6j
 8r+ZDcwrbjDkct0xuGTY3R/Kf6FGLugAWci/1KjXF5f5bMNwb0E+Sf1kYPNrZefWYqDG
 Vz2n9qa6iRJNYpzbSYoitRCSyC9ouI0kTDJUDtG3Jt9GQRCWsAvflnXCNJALSOeBbUKu
 clALvAG39xcwZzaE87yilHHerXzINtsMh2ghPxZa4JaLeSddCnbyO93nvvv9UtjVHofh
 x4Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719758063; x=1720362863;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=tW0tsHROR4p5YLwOqk8xa2rUpWs/nOmcbPjxjCZxRFM=;
 b=wV3nISKPHR+wVNeqvm02eauZOOVnj8WYkFBO6C38CBGOk8V85EwgM9f1TRbDw3RHzL
 O9brwYmub2ASEBYufD5xea7C+48AWVewLr+N0ykfmvTZ+/plx6Tysg2uT+204WqOFAKK
 bNtkTULbj/qww7Z6g+cjNCzC2fed2Ria41McBG+kq86E43K+28luqIYpgH4FOjwuoJV/
 DsK5boQLSUgVxCyFwMY0F49FJV7JnDcsjdOQBixImzKpX1QLFO5WQ5NhMj2ZRdmop3nI
 Be7eOATOvghFNy5FfIEWHqBGr2qBUxG4mP1BR02ewWaHIKADAlMaT/iaNaU+XxIX1Nuc
 /YUQ==
X-Gm-Message-State: AOJu0YzFYN1JdsFG5vTzwIAhenP0Ckum9wQXvTaGQkqf9VHep5i0D09y
 d1ekY5NqBn+7l7l06FD2mFEGStWFklRAJziBmbAxszLkB2xI0YIjJhz4hLC6gBVCzdjX4avuDoP
 AWElfHTy0orKUAmEROc5qa0bns55Wooki
X-Google-Smtp-Source: AGHT+IH1QgS20yo0+t1KWI13Ec9xYoZGHkO0qaupsvBauSvEsf5FZMeasGP26dQZQNImvWOOJIZpnCJ/WPk0yubnv/A=
X-Received: by 2002:a05:6402:5111:b0:57c:da58:51e7 with SMTP id
 4fb4d7f45d1cf-5879eaff6cemr2386501a12.1.1719758062591; Sun, 30 Jun 2024
 07:34:22 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Sun, 30 Jun 2024 07:34:21 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <871q4ej0f1.fsf@HIDDEN>
References: <87v83cfaqx.fsf@HIDDEN>
 <CADwFkm=fhoQGLgEHv6XsDPTzyeJBO+--krz+4RkoBoLjtGg1bQ@HIDDEN>
 <871q4ej0f1.fsf@HIDDEN>
MIME-Version: 1.0
Date: Sun, 30 Jun 2024 07:34:21 -0700
Message-ID: <CADwFkm=GGEz=a=uJR+fffdVKqiqG_D+athgYuZgKduE68aTEew@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Sandra Snan <sandra.snan@HIDDEN> writes:

> I'm glad I'm gonna get a chance to resend because I've fixed some
> more bugs in the version I've been dogfooding since I first sent
> that so I wanna send an updated version that has that.

Great, thanks.

> Normally when I'm sending Emacs lisp patches, it's on packages and
> they're usually in git already. Here it's a core file so the
> question I've got is what is the git repo I should make the change
> in? Then I could git send-email to this In-Reply-To thread id.

https://git.savannah.gnu.org/cgit/emacs.git

Please have a look at the CONTRIBUTE file in the Emacs source
distribution.

https://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71017: [PATCH] Flow single-paragraph messages
Resent-From: Sandra Snan <sandra.snan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 06 Jul 2024 20:51:01 +0000
Resent-Message-ID: <handler.71017.B71017.172029903815179 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71017
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 71017 <at> debbugs.gnu.org
Cc: Sandra Snan <sandra.snan@HIDDEN>
Received: via spool by 71017-submit <at> debbugs.gnu.org id=B71017.172029903815179
          (code B ref 71017); Sat, 06 Jul 2024 20:51:01 +0000
Received: (at 71017) by debbugs.gnu.org; 6 Jul 2024 20:50:38 +0000
Received: from localhost ([127.0.0.1]:46817 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sQCMf-0003wk-Ji
	for submit <at> debbugs.gnu.org; Sat, 06 Jul 2024 16:50:38 -0400
Received: from halsen.idiomdrottning.org ([74.207.231.133]:52762)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sandra.snan@HIDDEN>) id 1sQCMd-0003wc-87
 for 71017 <at> debbugs.gnu.org; Sat, 06 Jul 2024 16:50:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idiomdrottning.org;
 s=idiomdrottningorg; t=1720299000;
 bh=lmuQGTjWN4927bO4vKX5iEfXrWxxAbGq4HODUc/uCjQ=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=ne1SrF7uOmnq4i4ulU9Siilr+Y76/0vHmsdBqUdZzr59QqZdFI7ySEzJaJ+89fO2j
 ksDAjZWSzJ5AFFy7xyp/l0fKZz41ZJaXUkQl5eBj7QZ/emlMhzLObScdzPav3tIHur
 8c3Og/y+7s2Mz7ImmUkJywkEa06NSTvhqqKQCpEMWdSm+4zxcHdpm5cpYeTupe/APb
 KSHoeouyC8JY4cWeqzPqdlYqc2J4OCQBq1yL0OSQR4JbJJ/LIqe6DTWLVpVeTuavtn
 +IeaHyBOmqIGrO7vUO3j9FoPiMOtKm5oGciamve2Tjs8eHWRiFwF1SwgZLeaCnVPB3
 VSppWo58iCdJA==
Received: from localhost (31-211-247-254.customers.ownit.se [31.211.247.254])
 by halsen.idiomdrottning.org (Postfix) with ESMTPSA id B3E231ECA6;
 Sat,  6 Jul 2024 22:49:58 +0200 (CEST)
From: Sandra Snan <sandra.snan@HIDDEN>
Date: Sat,  6 Jul 2024 22:49:50 +0200
Message-Id: <20240706204950.2437581-1-sandra.snan@HIDDEN>
X-Mailer: git-send-email 2.39.2
In-Reply-To: <CADwFkm=GGEz=a=uJR+fffdVKqiqG_D+athgYuZgKduE68aTEew@HIDDEN>
References: <CADwFkm=GGEz=a=uJR+fffdVKqiqG_D+athgYuZgKduE68aTEew@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

This fixes two bugs when sending RFC 2646–formatted email.

First, the old code didn't refill or encode the last paragraph at all
unless there was at least one hard newline EOF. This was a bee to track
down because there were two separate issues at play. One was a a bug in
flow-fill.el where every paragraph except the last paragraph was
reflowed, but the last paragraph would stay hardwrapped. Manually
placing a hard newline at the end of the file was a workaround but I
don't always remember to do that. I managed to fix that bug a few months
ago.

Second, the old code borked up code indented with tabs and spaces
(iff that code had overly long lines), such as Lisp code. It could
sometimes insert extra whitespace in the middle of such long lines.
I fixed that bug shortly after the first one.

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.

Since the use-hard-newlines variable is buffer local and all this
reflowing is being done in a temp buffer, that variable is more than
useless so I've removed references to it.
---
 doc/misc/emacs-mime.texi |  7 ++---
 lisp/gnus/mml.el         | 29 ++++++++----------
 lisp/mail/flow-fill.el   | 65 +++++++++++++++++-----------------------
 3 files changed, 41 insertions(+), 60 deletions(-)

diff --git a/doc/misc/emacs-mime.texi b/doc/misc/emacs-mime.texi
index ef7ea61..7621a9a 100644
--- a/doc/misc/emacs-mime.texi
+++ b/doc/misc/emacs-mime.texi
@@ -1087,13 +1087,10 @@ terminated by soft newline characters are filled together and wrapped
 after the column decided by @code{fill-flowed-encode-column}.
 Quotation marks (matching @samp{^>* ?}) are respected.  The variable
 controls how the text will look in a client that does not support
-flowed text, the default is to wrap after 66 characters.  If hard
-newline characters are not present in the buffer, no flow encoding
-occurs.
+flowed text, the default is to wrap after 66 characters.
 
 You can customize the value of the @code{mml-enable-flowed} variable
-to enable or disable the flowed encoding usage when newline
-characters are present in the buffer.
+to enable or disable the flowed encoding usage.
 
 On decoding flowed text, lines with soft newline characters are filled
 together and wrapped after the column decided by
diff --git a/lisp/gnus/mml.el b/lisp/gnus/mml.el
index e3bc393..2db39dc 100644
--- a/lisp/gnus/mml.el
+++ b/lisp/gnus/mml.el
@@ -691,23 +691,18 @@ type detected."
 		   (t
 		    ;; Only perform format=flowed filling on text/plain
 		    ;; parts where there either isn't a format parameter
-		    ;; in the mml tag or it says "flowed" and there
-		    ;; actually are hard newlines in the text.
-		    (let (use-hard-newlines)
-		      (when (and mml-enable-flowed
-				 (string= type "text/plain")
-				 (not (string= (cdr (assq 'sign cont)) "pgp"))
-				 (or (null (assq 'format cont))
-				     (string= (cdr (assq 'format cont))
-					      "flowed"))
-				 (setq use-hard-newlines
-				       (text-property-any
-					(point-min) (point-max) 'hard 't)))
-			(fill-flowed-encode)
-			;; Indicate that `mml-insert-mime-headers' should
-			;; insert a "; format=flowed" string unless the
-			;; user has already specified it.
-			(setq flowed (null (assq 'format cont)))))
+		    ;; in the mml tag or it says "flowed".
+		    (when (and mml-enable-flowed
+			       (string= type "text/plain")
+			       (not (string= (cdr (assq 'sign cont)) "pgp"))
+			       (or (null (assq 'format cont))
+				   (string= (cdr (assq 'format cont))
+					    "flowed")))
+		      (fill-flowed-encode)
+		      ;; Indicate that `mml-insert-mime-headers' should
+		      ;; insert a "; format=flowed" string unless the
+		      ;; user has already specified it.
+		      (setq flowed (null (assq 'format cont))))
 		    ;; Prefer `utf-8' for text/calendar parts.
 		    (if (or charset
 			    (not (string= type "text/calendar")))
diff --git a/lisp/mail/flow-fill.el b/lisp/mail/flow-fill.el
index 919490e..5c9ae21 100644
--- a/lisp/mail/flow-fill.el
+++ b/lisp/mail/flow-fill.el
@@ -73,50 +73,39 @@ RFC 2646 suggests 66 characters for readability."
 ;;;###autoload
 (defun fill-flowed-encode (&optional buffer)
   (with-current-buffer (or buffer (current-buffer))
-    ;; No point in doing this unless hard newlines is used.
-    (when use-hard-newlines
-      (let ((start (point-min)) end)
-	;; Go through each paragraph, filling it and adding SPC
-	;; as the last character on each line.
-	(while (setq end (text-property-any start (point-max) 'hard 't))
-	  (save-restriction
-	    (narrow-to-region start end)
-	    (let ((fill-column (eval fill-flowed-encode-column t)))
-	      (fill-flowed-fill-buffer))
-	    (goto-char (point-min))
-	    (while (re-search-forward "\n" nil t)
-	      (replace-match " \n" t t))
-	    (goto-char (setq start (1+ (point-max)))))))
-      t)))
-
-(defun fill-flowed-fill-buffer ()
-  (let ((prefix nil)
-	(prev-prefix nil)
-	(start (point-min)))
-    (goto-char (point-min))
-    (while (not (eobp))
-      (setq prefix (and (looking-at "[> ]+")
-			(match-string 0)))
-      (if (equal prefix prev-prefix)
-	  (forward-line 1)
+    (let ((fill-column (eval fill-flowed-encode-column t))
+	  (start (point-min))
+	  end)
+      ;; Go through each paragraph, filling it and adding SPC
+      ;; as the last character on each line.
+      (while (and (< start (point-max))
+		  (setq end (or (text-property-any start (point-max) 'hard 't)
+				(point-max))))
 	(save-restriction
-	  (narrow-to-region start (point))
-	  (let ((fill-prefix prev-prefix))
-	    (fill-region (point-min) (point-max) t 'nosqueeze 'to-eop))
-	  (goto-char (point-max)))
-	(setq prev-prefix prefix
-	      start (point))))
-    (save-restriction
-      (narrow-to-region start (point))
-      (let ((fill-prefix prev-prefix))
-	(fill-region (point-min) (point-max) t 'nosqueeze 'to-eop)))))
+	  (narrow-to-region start end)
+	  (let ((prefix
+		 (concat "\n"
+			 (or (and (looking-at ">[> ]*")
+				  (match-string 0)) ""))))
+	    (goto-char start)
+	    (while (search-forward prefix nil t)
+	      (replace-match " " t t))
+	    (goto-char start)
+	    (while (< (+ (point) fill-column) (point-max))
+	      (let ((start (point)))
+		(forward-char fill-column)
+		(when (search-backward " " start t)
+		  (forward-char)
+		  (insert prefix)))))
+	  (setq start (1+ (point-max))))))
+    t))
 
 ;;;###autoload
 (defun fill-flowed (&optional buffer delete-space)
   "Apply RFC2646 decoding to BUFFER.
 If BUFFER is nil, default to the current buffer.
 
-If DELETE-SPACE, delete RFC2646 spaces padding at the end of
+If DELETE-SPACE, delete RFC3676 spaces padding at the end of
 lines."
   (with-current-buffer (or buffer (current-buffer))
     (let ((fill-column  (eval fill-flowed-display-column t)))
@@ -154,7 +143,7 @@ lines."
           ;; Delete the newline.
           (when (eq (following-char) ?\s)
             (delete-char 1))
-          ;; Hack: Don't do the flowing on the signature line.
+          ;; As per RFC3767: Don't do the flowing on the signature line.
           (when (and (not (looking-at "-- $"))
                      (eq (char-before (line-end-position)) ?\s))
             (while (and (not (eobp))
-- 
2.39.2

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#71017: [PATCH] Flow single-paragraph messages
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 07 Jul 2024 05:45:02 +0000
Resent-Message-ID: <handler.71017.B71017.17203310512622 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 71017
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Sandra Snan <sandra.snan@HIDDEN>, Eric Abrahamsen <eric@HIDDEN>
Cc: 71017 <at> debbugs.gnu.org
Received: via spool by 71017-submit <at> debbugs.gnu.org id=B71017.17203310512622
          (code B ref 71017); Sun, 07 Jul 2024 05:45:02 +0000
Received: (at 71017) by debbugs.gnu.org; 7 Jul 2024 05:44:11 +0000
Received: from localhost ([127.0.0.1]:47093 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sQKh0-0000gE-PQ
	for submit <at> debbugs.gnu.org; Sun, 07 Jul 2024 01:44:11 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41824)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sQKgy-0000g0-TG
 for 71017 <at> debbugs.gnu.org; Sun, 07 Jul 2024 01:44:09 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sQKgp-0000c1-8q; Sun, 07 Jul 2024 01:43:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=eTfDt4SKyk9XXbLNEieXGpihpkivrx9PPS4c+wx5/D4=; b=nmjp8T6Y8c2n3EdcJxlh
 53qkJKT5dBBjc5z5Qooon9CE1eGm5sa75hXNFiaf7L4ce+rmmRqLsr/JLvw7chtMZsgD8V4yUK8wG
 q0HXR/wgKxdcn2MBCZNWY2rE4AGrebvBrNz4+WKDRtH9ArrLBxeYwZOdqOioEAafkkTm3MIIOWk1k
 5XgHLIY0dH322oXkCSvFPCi6DQVu/3gt0jLRP6rX+gzS70U1VRn7C6+NzrJIf9hInSleM3rhs89gx
 GhVdOtmPm2/fPg72NPsFVY8Tr31uwQBjpHTHerMdTOsy4J2nHLxrP8BsHF9ledtlHKjoFHok+t+rA
 QI+vmTfxE+PLvg==;
Date: Sun, 07 Jul 2024 08:43:57 +0300
Message-Id: <86h6d13gf6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <20240706204950.2437581-1-sandra.snan@HIDDEN>
 (bug-gnu-emacs@HIDDEN)
References: <CADwFkm=GGEz=a=uJR+fffdVKqiqG_D+athgYuZgKduE68aTEew@HIDDEN>
 <20240706204950.2437581-1-sandra.snan@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: Sandra Snan <sandra.snan@HIDDEN>
> 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@HIDDEN>
> 
> 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.

Last modified: Sun, 7 Jul 2024 06:00:02 UTC

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