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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
Subject: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
Date: Sat, 28 Dec 2024 10:45:30 +0200

> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: Felix Lechner <felix.lechner <at> lease-up.com>,  56197 <at> debbugs.gnu.org,
>   stefankangas <at> gmail.com,  larsi <at> gnus.org
> Date: Sat, 28 Dec 2024 14:26:32 +0900
> 
> I can't say it feels very satisfactory; a switch like one imagined by
> Felix could be a step in the right direction; it'd be at least more
> concise in the project .dir-locals.  Would a patch implementing that be
> welcome?

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.

I also don't see what's wrong with the solution of having a special
function in .dir-locals.el.  We don't pretend that the default Emacs
behavior should necessarily fit all the use cases, and provide ample
opportunities for customizing Emacs behavior for that reason.
Defining a custom fill-paragraph function is a perfectly valid
solution, not very different from having a user option for the same
purpose.  So I'm not sure I understand why you prefer adding an
option, when the Guix project has already solved the problem in a
perfectly legitimate and clean way.

Previous Next

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