GNU bug report logs - #56197
lisp-fill-paragraph behavior changed in Emacs 28

Previous Next

Full log

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com,
 stefankangas <at> gmail.com
Subject: Re: bug#56197: lisp-fill-paragraph behavior changed in Emacs 28
Date: Sat, 04 Jan 2025 19:09:42 +0900

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

Hi Eli et al.,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

[...]

>> I don't see how a user option to control this could be useful, since
>> the preferred behavior is not only buffer-local, but also specific to
>> certain syntactic constructs.  But I won't object to having such an
>> option.
>
> Having the behavior defined per-project or even globally (reverting to
> the the pre-Emacs 28 behavior) via a simple option seems like it'd
> simplify things, and make them discoverable.

I tried fixing this generally, as it seems to me that something in
lisp-mode should be meet the needs of all lisp-derived languages such as
Scheme and not just Elisp.  I first added two tests, one of which
ensures no regression to the original bug that lead to this current
behavioral change (bug#28937) and the other one that should pass once
the issue reported here (bug#56197) is resolved.

The last patch is a WIP that didn't work; I was hoping that inserting
spaces corresponding to the width of the indent in the narrowed string
would cause the indent to be preserved only for the first line.  I don't
have other ideas at the moment; I'd appreciate if someone could tip in.

[0001-test-lisp-Add-new-test-for-filling-behavior-change.patch (text/x-patch, attachment)]

[0002-test-lisp-Add-a-test-checking-docstring-boundaries-w.patch (text/x-patch, attachment)]

[0003-wip-work-on-solution.patch (text/x-patch, attachment)]

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

If that's not easily fixable, perhaps I'll submit a patch to the paredit
project so that they stop relying on lisp-paragraph-fill [0] and instead
use the default (which is fill-paragraph).  That's how I came to notice
this behavior change in GNU Guix, which is written in Scheme; using
scheme-mode doesn't exhibit the issue since it's just using
fill-paragraph.

[0]  https://paredit.org/cgit/paredit/tree/paredit.el#n1066

-- 
Thanks,
Maxim

Previous Next

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