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

Previous Next

Package: emacs;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Fri, 24 Jun 2022 16:18:01 UTC

Severity: normal

Tags: patch

Found in version 28.1

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

Bug is archived. No further changes may be made.

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: lisp-fill-paragraph behavior changed in Emacs 28
Date: Thu, 16 Jan 2025 10:22:27 +0200
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: larsi <at> gnus.org,  felix.lechner <at> lease-up.com,  56197 <at> debbugs.gnu.org,
>   stefankangas <at> gmail.com
> Date: Thu, 16 Jan 2025 14:04:55 +0900
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, eliz <at> gnu.org,
> >> larsi <at> gnus.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
> >> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> >> Date: Sat,  4 Jan 2025 22:03:43 +0900
> >> 
> >> Starting with Emacs 28, filling strings now happens in a narrowed scope,
> >> and looses the leading indentation and can cause the string to extend
> >> past the fill-column value.  Introduce lisp-fill-paragraph-as-displayed
> >> as a new option allowing users to easily opt out of this new behavior.
> >
> > Thanks.  But this is not a user-level problem, so the variable to
> > control this should IMO be a defvar, not a defcustom.  Then Lisp
> > programs which need to get back old behavior for some reason could
> > bind the variable around the call.
> 
> I'm not sure.  A user (such as myself) may prefer the old behavior, and
> customize lisp-fill-paragraph-as-displayed (setting it to t) so that
> this behavior is now the default everywhere.  It also makes it
> more easily discoverable.  So unless you see a strong reason against
> using defcustom, it seems preferable to me than defvar.

Users can also set a defvar, if they want this globally.  However, the
original problem is not a global one, it is specific to some
situations in some particular major mode.

The important question here is: how common is the situation where a
user will prefer to set that globally?  I think this could only happen
if the user uses a major mode of just one variant of Lisp-like
languages, and especially if that one variant is not Emacs Lisp.

In addition, making it a defcustom means Lisp programs cannot easily
bind it to specific values when they need it (overriding user options
is considered unclean in Emacs).

So my preference is to introduce a defvar, and only promote it to a
user option if we have enough demand in the future.

> > P.S. I don't see your copyright assignment on file, so if you want to
> > contribute such large changes, let's please start your legal paperwork
> > of assigning the copyright to the FSF.  OK?
> 
> That's fine; I'm happy to assign my copyright w.r.t. Emacs changes to
> the FSF; please send the paperwork over!

Will do, thanks.




This bug report was last modified 109 days ago.

Previous Next


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