bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Cc: Felix Lechner <felix.lechner@lease-up.com>,  56197@debbugs.gnu.org,
>>   stefankangas@gmail.com,  larsi@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.

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 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.

For one, having to put that largish piece of evaluated code in the
.dir-locals.el of the project means each new developer is prompted to
trust it, and it makes it more intimidating/pollutes their user conf
file (being added to the 'safe-local-variable-values' value).

It's also not discoverable; a customizable option would help in this
regard.

-- 
Thanks,
Maxim