GNU bug report logs - #72870
[PATCH] Flow fill texts after the last hard newline

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72870 in the body.
You can then email your comments to 72870 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Pengji Zhang <me <at> pengjiz.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Flow fill texts after the last hard newline
Date: Thu, 29 Aug 2024 18:44:36 +0800

[Message part 1 (text/plain, inline)]

Tags: patch  Hello!

I found that function `fill-flowed-encode' would not fill texts 
after the last hard newline in a buffer. To reproduce, run 'emacs 
-Q' and then evaluate the following snippet:

--8<---------------cut here---------------start------------->8---
(with-current-buffer (get-buffer-create "*tmp-f=f*")
 (use-hard-newlines)
 (insert "1\n2")
 (fill-flowed-encode)
 (display-buffer (current-buffer)))
--8<---------------cut here---------------end--------------->8---

The expected output should be '1 2', but the actual is '1\n2'.

The first patch changes this.

[0001-Flow-fill-texts-after-the-last-hard-newline.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

Besides, I found that the test case 
'fill-flow-tests-fill-flowed-encode' in 'fill-flow-tests' does not 
actually test the function 'fill-flowed-encode', which requires 
'use-hard-newlines'[1], and the test input does not cover some 
behaviors of the function. The second patch improves it a bit.

[0002-Improve-tests-for-flow-fill.patch (text/x-patch, attachment)]

[Message part 5 (text/plain, inline)]

The second patch depends on the first one, without which the new 
test will fail. So I decided to submit both together. Please let 
me know if it is better to file another report.

Thanks!

Cheers,
Pengji

PS I have sent an email to assign <at> gnu.org, but have not got a 
response yet. I think I have not finished the copyright assignment 
process?

[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/mail/flow-fill.el#n77

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pengji Zhang <me <at> pengjiz.com>
Cc: 72870 <at> debbugs.gnu.org
Subject: Re: bug#72870: [PATCH] Flow fill texts after the last hard newline
Date: Sat, 07 Sep 2024 10:51:42 +0300

> From: Pengji Zhang <me <at> pengjiz.com>
> Date: Thu, 29 Aug 2024 18:44:36 +0800
> 
> I found that function `fill-flowed-encode' would not fill texts 
> after the last hard newline in a buffer. To reproduce, run 'emacs 
> -Q' and then evaluate the following snippet:
> 
> --8<---------------cut here---------------start------------->8---
> (with-current-buffer (get-buffer-create "*tmp-f=f*")
>   (use-hard-newlines)
>   (insert "1\n2")
>   (fill-flowed-encode)
>   (display-buffer (current-buffer)))
> --8<---------------cut here---------------end--------------->8---
> 
> The expected output should be '1 2', but the actual is '1\n2'.
> 
> The first patch changes this.
> 
> Besides, I found that the test case 
> 'fill-flow-tests-fill-flowed-encode' in 'fill-flow-tests' does not 
> actually test the function 'fill-flowed-encode', which requires 
> 'use-hard-newlines'[1], and the test input does not cover some 
> behaviors of the function. The second patch improves it a bit.
> 
> The second patch depends on the first one, without which the new 
> test will fail. So I decided to submit both together. Please let 
> me know if it is better to file another report.

Thanks.

AFAICT, this function exists for the special case of decoding email
messages.  Can email messages have flowed-encoded text without a hard
newline at the end?

> PS I have sent an email to assign <at> gnu.org, but have not got a 
> response yet. I think I have not finished the copyright assignment 
> process?

No.  Please ping them and CC me, so we could get your paperwork
process going.

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

From: Pengji Zhang <me <at> pengjiz.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72870 <at> debbugs.gnu.org
Subject: Re: bug#72870: [PATCH] Flow fill texts after the last hard newline
Date: Sun, 08 Sep 2024 19:56:28 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> AFAICT, this function exists for the special case of decoding 
> email messages. Can email messages have flowed-encoded text 
> without a hard newline at the end? 

I think you meant "encoding"? Anyway, if I understand it 
correctly, an email message should always end with a newline, but 
it is not necessarily a hard newline. For example, 'message.el' 
inserts a normal newline:

 https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el#n4944

I am not sure what other MUAs do, though.

>> PS I have sent an email to assign <at> gnu.org, but have not got a 
>> response yet. I think I have not finished the copyright 
>> assignment  process? 
> 
> No.  Please ping them and CC me, so we could get your paperwork 
> process going. 

Will do. Thanks!

Pengji

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

From: Pengji Zhang <me <at> pengjiz.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72870 <at> debbugs.gnu.org
Subject: Re: bug#72870: [PATCH] Flow fill texts after the last hard newline
Date: Mon, 09 Sep 2024 12:04:02 +0800

Pengji Zhang <me <at> pengjiz.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes: 
> 
>> AFAICT, this function exists for the special case of decoding 
>> email messages. Can email messages have flowed-encoded text 
>> without a hard newline at the end?  
> 
> I think you meant "encoding"? Anyway, if I understand it 
> correctly, an email message should always end with a newline, 
> but  it is not necessarily a hard newline. For example, 
> 'message.el'  inserts a normal newline: 
> 
>   https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/message.el#n4944 

I just realized this insertion of newline happens after encoding, 
so this is irrelevant here. Sorry.

It seems that during encoding, no such a newline is added at all. 
To reproduce:

 - Run 'emacs -Q'
 - C-x m C-c C-b
 - M-x use-hard-newlines RET n
 - C-x f 10 RET
 - Eval: (dotimes (i 10) (insert "word "))
 - RET RET
 - Eval: (dotimes (i 10) (insert "word "))
 - M-q
 - C-u M-x mml-preview RET

In the preview buffer, the first paragraph is filled but the 
second is not.

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

From: Pengji Zhang <me <at> pengjiz.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72870 <at> debbugs.gnu.org
Subject: Re: bug#72870: [PATCH] Flow fill texts after the last hard newline
Date: Wed, 09 Oct 2024 17:02:32 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> PS I have sent an email to assign <at> gnu.org, but have not got a
>> response yet. I think I have not finished the copyright assignment
>> process?
>
> No. Please ping them and CC me, so we could get your paperwork process
> going.

Hi Eli! Yesterday I was told that my assignment process had been
complete.

Message #22 received at 72870-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pengji Zhang <me <at> pengjiz.com>
Cc: 72870-done <at> debbugs.gnu.org
Subject: Re: bug#72870: [PATCH] Flow fill texts after the last hard newline
Date: Sat, 12 Oct 2024 15:31:33 +0300

> From: Pengji Zhang <me <at> pengjiz.com>
> Cc: 72870 <at> debbugs.gnu.org
> Date: Wed, 09 Oct 2024 17:02:32 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> PS I have sent an email to assign <at> gnu.org, but have not got a
> >> response yet. I think I have not finished the copyright assignment
> >> process?
> >
> > No. Please ping them and CC me, so we could get your paperwork process
> > going.
> 
> Hi Eli! Yesterday I was told that my assignment process had been
> complete.

Thanks, so I've now installed the patches, and I'm closing this bug.

Previous Next

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