bug#50842: 28.0.50; problem with fill-paragraph

bug#50842: 28.0.50; problem with fill-paragraph

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Hello,

When using M-q (fill-paragraph) in message-mode with latest version from
git-master, the result is not as I would expect.

Example buffer:

--8<---------------cut here---------------start------------->8---
From: xxx
To: xxx
Subject: xxx
--text follows this line--
You wrote:

> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla        
>           bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla      
>           bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla      
--8<---------------cut here---------------end--------------->8---

When typing M-q in the quoted text, I get this:

--8<---------------cut here---------------start------------->8---
> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla > bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla > bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla
--8<---------------cut here---------------end--------------->8---

But I would like to get this (as with Emacs-27.2):

--8<---------------cut here---------------start------------->8---
> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
> bla bla bla bla bla
--8<---------------cut here---------------end--------------->8---

How could I get back the behaviour of Emacs-27.2 please?

TIA for any hints,
-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Peter Münster <pm@a16n.net> writes:

> When using M-q (fill-paragraph) in message-mode with latest version from
> git-master, the result is not as I would expect.
>
> Example buffer:
>
> From: xxx
> To: xxx
> Subject: xxx
> --text follows this line--
> You wrote:
>
>> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla        
>>           bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla      
>>           bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla      

I'm unable to reproduce this problem.  Here's my steps to reproduce:

emacs -Q
C-x m

then I pasted in the text from your mail and hit `M-q' in the quoted
text, and I got:


[-- Attachment #2: Type: image/png, Size: 53335 bytes --]

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]


Are there any additional steps needed to reproduce the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: 28.0.50; problem with fill-paragraph

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

On Tue, Sep 28 2021, Lars Ingebrigtsen wrote:

> Are there any additional steps needed to reproduce the problem?

No. But it seems, that Gnus does some whitespace-cleanup at some point.
Please copy from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50842
then it should work. Just keep all the whitespace.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

> No. But it seems, that Gnus does some whitespace-cleanup at some point.
> Please copy from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50842
> then it should work. Just keep all the whitespace.

I tried that, and I still can't reproduce the problem.  (This is on the
current trunk.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: 28.0.50; problem with fill-paragraph

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]

On Tue, Sep 28 2021, Lars Ingebrigtsen wrote:

> I tried that, and I still can't reproduce the problem.  (This is on the
> current trunk.)

Strange. There are perhaps some differences elsewhere. Here the
information about my environment:

In GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2021-09-28 built on ws
Repository revision: 7757e9b204e58419897874265a448d599dd9c69f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: openSUSE Leap 15.3

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_CTYPE: en_GB.utf8
  value of $LC_MESSAGES: en_GB.utf8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 49939 7426)
 (symbols 48 6626 1)
 (strings 32 18468 1279)
 (string-bytes 1 609958)
 (vectors 16 12862)
 (vector-slots 8 178826 7920)
 (floats 8 22 41)
 (intervals 56 220 0)
 (buffers 992 12))

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

> In GNU Emacs 28.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
>  of 2021-09-28 built on ws
> Repository revision: 7757e9b204e58419897874265a448d599dd9c69f
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
> System Description: openSUSE Leap 15.3

Looks similar to mine:

In GNU Emacs 28.0.50 (build 41, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-09-28 built on elva
Repository revision: 76e846f92a3c625fe524c81aa996327fba5a9e65
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Can anybody else reproduce this problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: 28.0.50; problem with fill-paragraph

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 28 Sep 2021 08:21:05 +0200
> Cc: 50842@debbugs.gnu.org
> 
> Peter Münster <pm@a16n.net> writes:
> 
> > No. But it seems, that Gnus does some whitespace-cleanup at some point.
> > Please copy from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50842
> > then it should work. Just keep all the whitespace.
> 
> I tried that, and I still can't reproduce the problem.  (This is on the
> current trunk.)

Strange, because fore me it is 100% reproducible, with the current
master.

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Strange, because fore me it is 100% reproducible, with the current
> master.

Can you describe the steps you take to reproduce it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: 28.0.50; problem with fill-paragraph

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: pm@a16n.net,  50842@debbugs.gnu.org
> Date: Tue, 28 Sep 2021 09:12:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Strange, because fore me it is 100% reproducible, with the current
> > master.
> 
> Can you describe the steps you take to reproduce it?

Exactly as you did:

  emacs -Q
  C-x m
  copy/paste the example, starting from "You wrote"
  go to the first line of "bla bla"
  type C-q

Is it possible that you typed C-q on a quoted line that is not the
first one?  Because on any other line it indeed works as expected.

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Is it possible that you typed C-q on a quoted line that is not the
> first one?  Because on any other line it indeed works as expected.

Ah, that's the missing detail.  With point in the first line, I can
reproduce the problem, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: Fwd: bug#50842: 28.0.50; problem with fill-paragraph

[No Wayman]

Apologies. I used the "Reply" button on the bug archive page and 
didn't realize it would just reply to Lars.
I hope I'm forwarding this to the right address so it can be seen 
by all in the thread.

> Ah, that's the missing detail.

 Apologies if this is an unwelcome intrusion, but I'm currently 
 working on a package
 to prevent this type of confusion during bug reproduction:

 https://www.github.com/progfolio/yodel


 The basic idea is to provide macros which make declaring a 
 reproduction case easier.
 It runs the test and provides a formatted report which others can 
 run and compare results.
 The reports can be re-formatted easily after they've been run.
 Yodel currently supports github markdown, reddit markdown, Org 
 syntax, and can easily be extended to support other formats.

 As a case study, I wrote a test for this bug.
 The yodel-file macro removes the ambiguity of "Copy this into a 
 buffer, do this with point here, etc".
 The yodel macro runs the test locally in a temporary, clean Emacs 
 environment, and presents the formatted report.
 Here's the resultant report in Org syntax:


 * YODEL REPORT [2021-09-28 11:12:45]

 #+begin_src emacs-lisp :lexical t :results silent
 (yodel
   :post*
   (yodel-file
     :point "|"
     :with*
     "From: xxx
 To: xxx
 Subject: xxx

 You wrote:
> | bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla 
> bla bla bla bla bla
>           bla bla bla bla bla bla bla bla bla bla bla bla bla 
>           bla bla bla bla bla
>           bla bla bla bla bla bla bla bla bla bla bla bla bla 
>           bla bla bla bla bla     "
     :then*
     (message-mode)
     (fill-paragraph)
     (print
      (buffer-substring-no-properties
       (point-min)
       (point-max)))))

 #+end_src


 ** STDOUT:

 #+begin_src emacs-lisp :lexical t :results silent
 "From: xxx
 To: xxx
 Subject: xxx
 --text follows this line--
 You wrote:

> bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla 
> bla
 bla bla bla > bla bla bla bla bla bla bla bla bla bla bla bla bla 
 bla
 bla bla bla bla > bla bla bla bla bla bla bla bla bla bla bla bla 
 bla
 bla bla bla bla bla"
 #+end_src

 ** Environment

 - =emacs version=: GNU Emacs 28.0.50 (build 1, 
   x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d 
   scroll bars)
  of 2021-09-23
 - =system type=: gnu/linux



 Just food for thought on how we could better approach reproducing 
 bugs.

 Thanks,
 Nick

bug#50842: Fwd: bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

No Wayman <iarchivedmywholelife@gmail.com> writes:

>  The basic idea is to provide macros which make declaring a 
>  reproduction case easier.

It's an interesting idea, but I think it's unlikely that we'd get many
people to submit bug reports using something as complicated as this,
really.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50842: Fwd: bug#50842: 28.0.50; problem with fill-paragraph

[No Wayman]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> No Wayman <iarchivedmywholelife@gmail.com> writes:
>
>>  The basic idea is to provide macros which make declaring a 
>>  reproduction case easier.
>
> It's an interesting idea, but I think it's unlikely that we'd 
> get many
> people to submit bug reports using something as complicated as 
> this,
> really.

I agree that elisp novices probably wouldn't author many reports 
themselves.
However, there's benefit beyond that.
We use a similar macro for diagnosing bugs with straight.el and 
there are users who know enough elisp
to write reports.
The first thing I do when I get a bug report is encode it via that 
macro and have the user who reported it run it/share results. That 
confirms that there is actually a bug and we're on the same page 
about what is expected/happening. It reduces the time wasted on 
"Oh yeah, I forgot to mention a step" or "Oh yeah, I forgot to do 
that step", etc. It's even more beneficial when you have multiple 
users effected by the same bug. IME, It's a lot more efficient to 
ask someone "please paste this in your *scratch* buffer, eval, and 
copy back the results".
Once the bug is closed, the body of the macro is often still 
useful as a regression test, too.

Again, just food for thought.

bug#50842: Fwd: bug#50842: 28.0.50; problem with fill-paragraph

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@gmail.com>
> Date: Wed, 29 Sep 2021 10:48:00 -0400
> Cc: 50842@debbugs.gnu.org
> 
> Again, just food for thought.

Thanks.

An alternative idea is to use open-dribble-file and/or recent-keys to
generate precise recipes.

bug#50842: 28.0.50; problem with fill-paragraph

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

> When using M-q (fill-paragraph) in message-mode with latest version from
> git-master, the result is not as I would expect.

This should now be fixed again.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no