From debbugs-submit-bounces@debbugs.gnu.org Tue May 20 18:51:34 2025 Received: (at submit) by debbugs.gnu.org; 20 May 2025 22:51:34 +0000 Received: from localhost ([127.0.0.1]:38445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHVo4-00078c-EG for submit@debbugs.gnu.org; Tue, 20 May 2025 18:51:34 -0400 Received: from lists.gnu.org ([2001:470:142::17]:49352) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHVo0-00077R-NR for submit@debbugs.gnu.org; Tue, 20 May 2025 18:51:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uHVnq-0004v1-Ks for bug-gnu-emacs@gnu.org; Tue, 20 May 2025 18:51:19 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uHVnn-0001XL-Jf for bug-gnu-emacs@gnu.org; Tue, 20 May 2025 18:51:17 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D97D3240027 for ; Wed, 21 May 2025 00:51:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1747781469; bh=I/PIEVlWRJgrOtWPzccQHnvRruhgFUzfVPr3ErBod+Q=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=jbxiU1Snn8AhDVtASKnVYU7ScTafwEg7lXzKvKifLGzDmg4wr+9x+avFXt9f73McA 8Dcvat9BGNDSsG2pYAiaoz9B1+wOlrPHFTG4Gh2up5JmXP5iTj3uP9IpIbaHQv34ln N4bupdnqCqn7vErwkz7b58GdsQq13lk0dYcbO0jBw/foCVpzI+JpoK5k/dzvRkLgns 7AQAG4+7AjxjXt6VWnZOFbJ85JWoGJk4ZCrKIQTwLEB2PDp0zhCJpvowRodXEqrCn+ 0UOVZr0LpELIcOchFb/WlcrxVx5FuWHyIhYXwqrIHGSlrvSG5goDF1PX0q+fzRLhqc P+wa41HrVV9Fg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4b28t50K7pz6twK; Wed, 21 May 2025 00:51:09 +0200 (CEST) From: Mekeor Melire To: bug-gnu-emacs@gnu.org Subject: 30.0.91; In Gnus, when yanking an article, all its newlines become soft Date: Tue, 20 May 2025 22:50:21 +0000 Message-ID: <87h61eew2a.fsf@posteo.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=185.67.36.65; envelope-from=mekeor@posteo.de; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable GNU Emacs and Gnus support RFC 3676 (obsoleting RFC 2646) =E2=80=9CThe Text/Plain Format and DelSp Parameters=E2=80=9D as described in (info "(emacs-mime) Flowed text"). But when replying to an article, or more specifically, when yanking an article (no matter whether it's Fixed or Flowed) while composing a message, all yanked newlines become soft newlines, or more specifically, no newline has the text-property `hard' set to t. As a consequence, when the composed message is sent with Format=3DFlowed, it will be encoded wrongly and its readers will see it terribly displayed. How to arrive at this misbehavior? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Open an article of content-type text/plain with Gnus. Gnus decodes and inlines the article. If the article has the Format MIME-parameter set to Flowed, the function `mm-inline-text' inlines the article and refills it to the column specified per `fill-flowed-display-column' variable by calling `fill-flowed'. `fill-flowed' itself can tell which newlines are soft and which are hard because they are respectively present as either as the sequence SPC CRLF, or just CRLF without preceding SPC. But after `fill-flowed' is called, both types of newlines are just CRLF and even without any text-property. 2. Start composing a reply to the article, e.g. by pressing R, bound `gnus-article-reply-with-original' in `gnus-article-mode-map'. Gnus will set up a compose buffer and yank the original article with citation prefix. Yanking happens by first calling `gnus-copy-article-buffer', which copies the original article, from the buffer where it is displayed and read, to the new composing message buffer while removing all text-properties. (Then, yanking will continue by adding the citation prefixes.) The resulting buffer has only soft newlines. A. Note that this behavior is only a bug if the composed reply has Format parameter set to Flowed, which Emacs decides to do if at least once in the buffer, the text-property `hard' is set to t. See =E2=80=9COn encoding text, regardless of =E2=80=98use-hard-newlines= =E2=80=99, lines terminated by soft newline characters are filled together and wrapped=E2=80=9D at (info "(emacs-mime) Flowed text") and the form (setq use-hard-newlines (text-property-any (point-min) (point-max) 'hard 't)) in definition of function `mml-generate-mime-1' [2]. What would be the correct behavior? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D X. In my opinion, we should retain the property that it makes no difference in effect between first turning on `use-hard-newlines' and then yanking, or the other way around. Y. In my opinion, we should continue to use the `hard' text-property on hard newlines in the composing buffer, because most filling related commands know about it. Z. In my opinion, when yanking a Fixed formatted article, all yanked newlines should become hard or rather be interpreted as hard, i.e. they should get the `hard' text-property set to t. This is because it's hard to tell if we can interpret a newline as soft newline, or if it's really meant to be hard, e.g. because it's a poem. [3] Thus, I think that yanking hard newlines from Format=3DFlowed articles should have `hard' set to t in the compose buffer. Similarly, any newline yanked from a Fixed [4] article should have `hard' set to t as well. And the detection described at (A.), whether Format parameter should be set to Fixed for the composing message, should be changed, so that it only checks whether `use-hard-newlines' is non-nil rather than looking for any `hard' property set to t, because this would conflict with (X.). How can we approach the proposed correct behavior? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =CE=B1. Let's fix `fill-flowed' so that it sets `hard' to t on hard newlines after refilling. Please find attached a patch for this. =CE=B2. Let's fix `gnus-copy-article-buffer' so that it keeps `hard' text-properties on newlines. Please find attached a patch for this. I'm not sure if it suffices to fix this function, because we want the `hard' propertized hard newlines in many cases: - Content-Type text/plain, without any Format specification; or with Format specification set to Fixed or Flowed - Content-Type multipart/* where for each text/plain part we want proper hard newlines. =CE=B3. Let's fix (Z) but I'm yet sure how. Footnotes =3D=3D=3D=3D=3D=3D=3D=3D=3D [2] Oops, in my init.el, I have configured `message-citation-line-format' to contain a `hard-newline. I guess, all my sent reply-messages have Format=3DFlowed? [3] There might be approximating heuristics for this. But what'd be more important is to provide users commands so that they can convert hard and soft newlines within a region or paragraph back and forth, as desired. But that's future work. [4] Be it Fixed by explicitly setting Format=3DFixed, or by omitting the Format parameter completely. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=fill-flowed.diff diff --git a/lisp/mail/flow-fill.el b/lisp/mail/flow-fill.el index 683aa981864..2c22d245ee9 100644 --- a/lisp/mail/flow-fill.el +++ b/lisp/mail/flow-fill.el @@ -170,7 +170,8 @@ fill-flowed (fill-region (line-beginning-position) (line-end-position) 'left 'nosqueeze)))))) - (forward-line 1))))) + (forward-line 1) + (put-text-property (1- (point)) (point) 'hard t))))) (make-obsolete-variable 'fill-flowed-encode-tests nil "27.1") (defvar fill-flowed-encode-tests) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gnus-copy-article-buffer.diff diff --git a/lisp/gnus/gnus-msg.el b/lisp/gnus/gnus-msg.el index 807c4e17a33..e4370b43eb3 100644 --- a/lisp/gnus/gnus-msg.el +++ b/lisp/gnus/gnus-msg.el @@ -851,10 +851,21 @@ gnus-copy-article-buffer (gnus-remove-text-with-property 'gnus-prev) (gnus-remove-text-with-property 'gnus-next) (gnus-remove-text-with-property 'gnus-decoration) - (insert - (prog1 - (buffer-substring-no-properties (point-min) (point-max)) - (erase-buffer))) + ;; Remove all text-properties except for non-nil `hard' on + ;; newlines: + (let ((pt (point-min)) (end (point-max))) + (goto-char pt) + (while (search-forward "\n" end 'move) + ;; Remove all text properties before newline. + (set-text-properties pt (match-beginning 0) nil) + ;; Replace newline with hard or soft newline. + (replace-match + (if (get-text-property (match-beginning 0) 'hard) + hard-newline "\n")) + ;; Start next loop with point after newline. + (setq pt (goto-char (match-end 0)))) + ;; Remove all text properties after last newline. + (set-text-properties pt (point) nil)) ;; Find the original headers. (set-buffer gnus-original-article-buffer) (goto-char (point-min)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 24 05:37:48 2025 Received: (at 78519) by debbugs.gnu.org; 24 May 2025 09:37:48 +0000 Received: from localhost ([127.0.0.1]:57207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uIlK7-0001Vj-Kg for submit@debbugs.gnu.org; Sat, 24 May 2025 05:37:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46088) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uIlK5-0001VB-C8 for 78519@debbugs.gnu.org; Sat, 24 May 2025 05:37:46 -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 ) id 1uIlJz-0004Xa-44; Sat, 24 May 2025 05:37:39 -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=FNUnJEKqug2xAW8J34YzyqFoPVliBMaq5Cq8I7gWBCs=; b=cZlsirSVpdHvFTjLeZ8w +z62k6P37CTXdmETl8ZM1WISzSZ7ysMxWqz5IfMP+WXu/aUfqOBnsp4Bdzp0S7ntFl9OHVV0b50jo DQ21Sp6rRtvuQy5H7arzYRgElcOF5FPT1LjmHi3PRjkq9zyvytv4sg7CLJnCJxsbL1jxH0EkaQ+v6 GB4ff0vTs+0KtwLXne/v+uBtlQj9X2SQWg2NL1H6LUO5TopzprMgbVjEHBr3615fI6cuKRP3q+i5p +P/r1PwO7jylJ0UdMS0C63RiVAK35T3GWvENZ9pw1U6JRgiXLH3RuPNu15kIr8R7YKs+pvkznNapr I322hPjGTvGNcQ==; Date: Sat, 24 May 2025 12:37:36 +0300 Message-Id: <86iklq1h9b.fsf@gnu.org> From: Eli Zaretskii To: Mekeor Melire , Eric Abrahamsen In-Reply-To: <87h61eew2a.fsf@posteo.de> (message from Mekeor Melire on Tue, 20 May 2025 22:50:21 +0000) Subject: Re: bug#78519: 30.0.91; In Gnus, when yanking an article, all its newlines become soft References: <87h61eew2a.fsf@posteo.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78519 Cc: 78519@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mekeor Melire > Date: Tue, 20 May 2025 22:50:21 +0000 > > GNU Emacs and Gnus support RFC 3676 (obsoleting RFC 2646) “The > Text/Plain Format and DelSp Parameters” as described in (info > "(emacs-mime) Flowed text"). But when replying to an article, or > more specifically, when yanking an article (no matter whether it's > Fixed or Flowed) while composing a message, all yanked newlines > become soft newlines, or more specifically, no newline has the > text-property `hard' set to t. As a consequence, when the composed > message is sent with Format=Flowed, it will be encoded wrongly and > its readers will see it terribly displayed. > > > How to arrive at this misbehavior? > ================================== > > 1. Open an article of content-type text/plain with Gnus. Gnus > decodes and inlines the article. If the article has the Format > MIME-parameter set to Flowed, the function `mm-inline-text' > inlines the article and refills it to the column specified per > `fill-flowed-display-column' variable by calling > `fill-flowed'. `fill-flowed' itself can tell which newlines are > soft and which are hard because they are respectively present as > either as the sequence SPC CRLF, or just CRLF without preceding > SPC. But after `fill-flowed' is called, both types of newlines are > just CRLF and even without any text-property. > > 2. Start composing a reply to the article, e.g. by pressing R, > bound `gnus-article-reply-with-original' in > `gnus-article-mode-map'. Gnus will set up a compose buffer and > yank the original article with citation prefix. Yanking happens by > first calling `gnus-copy-article-buffer', which copies the > original article, from the buffer where it is displayed and read, > to the new composing message buffer while removing all > text-properties. (Then, yanking will continue by adding the > citation prefixes.) The resulting buffer has only soft newlines. > > A. Note that this behavior is only a bug if the composed reply has > Format parameter set to Flowed, which Emacs decides to do if at > least once in the buffer, the text-property `hard' is set to > t. See “On encoding text, regardless of ‘use-hard-newlines’, lines > terminated by soft newline characters are filled together and > wrapped” at (info "(emacs-mime) Flowed text") and the form (setq > use-hard-newlines (text-property-any (point-min) (point-max) 'hard > 't)) in definition of function `mml-generate-mime-1' [2]. > > > What would be the correct behavior? > =================================== > > X. In my opinion, we should retain the property that it makes no > difference in effect between first turning on `use-hard-newlines' > and then yanking, or the other way around. > > Y. In my opinion, we should continue to use the `hard' > text-property on hard newlines in the composing buffer, because > most filling related commands know about it. > > Z. In my opinion, when yanking a Fixed formatted article, all > yanked newlines should become hard or rather be interpreted as > hard, i.e. they should get the `hard' text-property set to t. This > is because it's hard to tell if we can interpret a newline as soft > newline, or if it's really meant to be hard, e.g. because it's a > poem. [3] > > Thus, I think that yanking hard newlines from Format=Flowed > articles should have `hard' set to t in the compose > buffer. Similarly, any newline yanked from a Fixed [4] article > should have `hard' set to t as well. And the detection described > at (A.), whether Format parameter should be set to Fixed for the > composing message, should be changed, so that it only checks > whether `use-hard-newlines' is non-nil rather than looking for any > `hard' property set to t, because this would conflict with (X.). > > > How can we approach the proposed correct behavior? > ================================================== > > α. Let's fix `fill-flowed' so that it sets `hard' to t on hard > newlines after refilling. Please find attached a patch for this. > > β. Let's fix `gnus-copy-article-buffer' so that it keeps `hard' > text-properties on newlines. Please find attached a patch for > this. I'm not sure if it suffices to fix this function, because we > want the `hard' propertized hard newlines in many cases: > > - Content-Type text/plain, without any Format specification; or > with Format specification set to Fixed or Flowed > - Content-Type multipart/* where for each text/plain part we > want proper hard newlines. > > γ. Let's fix (Z) but I'm yet sure how. > > > Footnotes > ========= > > [2] Oops, in my init.el, I have configured > `message-citation-line-format' to contain a `hard-newline. I > guess, all my sent reply-messages have Format=Flowed? > > [3] There might be approximating heuristics for this. But what'd > be more important is to provide users commands so that they > can convert hard and soft newlines within a region or > paragraph back and forth, as desired. But that's future work. > > [4] Be it Fixed by explicitly setting Format=Fixed, or by omitting > the Format parameter completely. Eric, any comments? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 07 04:21:45 2025 Received: (at 78519) by debbugs.gnu.org; 7 Jun 2025 08:21:45 +0000 Received: from localhost ([127.0.0.1]:46745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNooC-0004g6-Pm for submit@debbugs.gnu.org; Sat, 07 Jun 2025 04:21:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49658) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNooA-0004fm-NA for 78519@debbugs.gnu.org; Sat, 07 Jun 2025 04:21:43 -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 ) id 1uNoo4-0003lJ-JD; Sat, 07 Jun 2025 04:21:36 -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=n+F4KFgtA5UdPhZucyxOjSpO5sNSQPG+cWzcuPWESE0=; b=e172hrnazkm0fgTK7VTv Chwp2EbcL82f28gMzJcnnf/+Hq3Oz30Bki48zNbGUCXrBY4t6AG5v5GoOHsFrQn2deahlr8sIcPsJ uspJ3pgqhTFf2MPT42njp0PGshMuA8s+VXMg41mEkTvE6CMrlfah4daijuEdcCRWejHkIz4abIFOH eA8qH5ylw99RXU4+lHhDOK6JnBuLvoU6HdcXfgxyiJ3hFGw449dYK9Qgs59uFkPULr6wERocCTPKc Ncep27eWN0k1wUEIg0tvCND88GBWbTQ4VXBTZb4jyjGYJAqcGsYDnOs9w8DMSZOqccGFPDBBzR7p9 WeshTlfhsXvsFQ==; Date: Sat, 07 Jun 2025 11:21:34 +0300 Message-Id: <867c1oj71t.fsf@gnu.org> From: Eli Zaretskii To: eric@ericabrahamsen.net In-Reply-To: <86iklq1h9b.fsf@gnu.org> (message from Eli Zaretskii on Sat, 24 May 2025 12:37:36 +0300) Subject: Re: bug#78519: 30.0.91; In Gnus, when yanking an article, all its newlines become soft References: <87h61eew2a.fsf@posteo.de> <86iklq1h9b.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78519 Cc: mekeor@posteo.de, 78519@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ping! Eric, could you please chime in? > Cc: 78519@debbugs.gnu.org > Date: Sat, 24 May 2025 12:37:36 +0300 > From: Eli Zaretskii > > > From: Mekeor Melire > > Date: Tue, 20 May 2025 22:50:21 +0000 > > > > GNU Emacs and Gnus support RFC 3676 (obsoleting RFC 2646) “The > > Text/Plain Format and DelSp Parameters” as described in (info > > "(emacs-mime) Flowed text"). But when replying to an article, or > > more specifically, when yanking an article (no matter whether it's > > Fixed or Flowed) while composing a message, all yanked newlines > > become soft newlines, or more specifically, no newline has the > > text-property `hard' set to t. As a consequence, when the composed > > message is sent with Format=Flowed, it will be encoded wrongly and > > its readers will see it terribly displayed. > > > > > > How to arrive at this misbehavior? > > ================================== > > > > 1. Open an article of content-type text/plain with Gnus. Gnus > > decodes and inlines the article. If the article has the Format > > MIME-parameter set to Flowed, the function `mm-inline-text' > > inlines the article and refills it to the column specified per > > `fill-flowed-display-column' variable by calling > > `fill-flowed'. `fill-flowed' itself can tell which newlines are > > soft and which are hard because they are respectively present as > > either as the sequence SPC CRLF, or just CRLF without preceding > > SPC. But after `fill-flowed' is called, both types of newlines are > > just CRLF and even without any text-property. > > > > 2. Start composing a reply to the article, e.g. by pressing R, > > bound `gnus-article-reply-with-original' in > > `gnus-article-mode-map'. Gnus will set up a compose buffer and > > yank the original article with citation prefix. Yanking happens by > > first calling `gnus-copy-article-buffer', which copies the > > original article, from the buffer where it is displayed and read, > > to the new composing message buffer while removing all > > text-properties. (Then, yanking will continue by adding the > > citation prefixes.) The resulting buffer has only soft newlines. > > > > A. Note that this behavior is only a bug if the composed reply has > > Format parameter set to Flowed, which Emacs decides to do if at > > least once in the buffer, the text-property `hard' is set to > > t. See “On encoding text, regardless of ‘use-hard-newlines’, lines > > terminated by soft newline characters are filled together and > > wrapped” at (info "(emacs-mime) Flowed text") and the form (setq > > use-hard-newlines (text-property-any (point-min) (point-max) 'hard > > 't)) in definition of function `mml-generate-mime-1' [2]. > > > > > > What would be the correct behavior? > > =================================== > > > > X. In my opinion, we should retain the property that it makes no > > difference in effect between first turning on `use-hard-newlines' > > and then yanking, or the other way around. > > > > Y. In my opinion, we should continue to use the `hard' > > text-property on hard newlines in the composing buffer, because > > most filling related commands know about it. > > > > Z. In my opinion, when yanking a Fixed formatted article, all > > yanked newlines should become hard or rather be interpreted as > > hard, i.e. they should get the `hard' text-property set to t. This > > is because it's hard to tell if we can interpret a newline as soft > > newline, or if it's really meant to be hard, e.g. because it's a > > poem. [3] > > > > Thus, I think that yanking hard newlines from Format=Flowed > > articles should have `hard' set to t in the compose > > buffer. Similarly, any newline yanked from a Fixed [4] article > > should have `hard' set to t as well. And the detection described > > at (A.), whether Format parameter should be set to Fixed for the > > composing message, should be changed, so that it only checks > > whether `use-hard-newlines' is non-nil rather than looking for any > > `hard' property set to t, because this would conflict with (X.). > > > > > > How can we approach the proposed correct behavior? > > ================================================== > > > > α. Let's fix `fill-flowed' so that it sets `hard' to t on hard > > newlines after refilling. Please find attached a patch for this. > > > > β. Let's fix `gnus-copy-article-buffer' so that it keeps `hard' > > text-properties on newlines. Please find attached a patch for > > this. I'm not sure if it suffices to fix this function, because we > > want the `hard' propertized hard newlines in many cases: > > > > - Content-Type text/plain, without any Format specification; or > > with Format specification set to Fixed or Flowed > > - Content-Type multipart/* where for each text/plain part we > > want proper hard newlines. > > > > γ. Let's fix (Z) but I'm yet sure how. > > > > > > Footnotes > > ========= > > > > [2] Oops, in my init.el, I have configured > > `message-citation-line-format' to contain a `hard-newline. I > > guess, all my sent reply-messages have Format=Flowed? > > > > [3] There might be approximating heuristics for this. But what'd > > be more important is to provide users commands so that they > > can convert hard and soft newlines within a region or > > paragraph back and forth, as desired. But that's future work. > > > > [4] Be it Fixed by explicitly setting Format=Fixed, or by omitting > > the Format parameter completely. > > Eric, any comments? > > > >