Subject: bug#56197: lisp-fill-paragraph behavior changed in Emacs 28

From: Eli Zaretskii <[email-masked]>
Date: Thu, 16 Jan 2025 10:22:27 +0200

> From: Maxim Cournoyer <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>   [email-masked]
> Date: Thu, 16 Jan 2025 14:04:55 +0900
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> Cc: Maxim Cournoyer <[email-masked]>, [email-masked],
> >> [email-masked], [email-masked], [email-masked]
> >> From: Maxim Cournoyer <[email-masked]>
> >> 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.