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

[Eli Zaretskii]

> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, Stefan Kangas
>  <stefankangas@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Lars Ingebrigtsen
>  <larsi@gnus.org>
> Date: Wed, 25 Dec 2024 12:15:44 -0800
> 
> > fill the string using fill-column, or [...] fill the text as is in the
> > buffer
> 
> > It's now filling that string as if it, well, is a string, so that if
> > you insert it somewhere, the lines have similar lengths.  The previous
> > behaviour was to fill "what you see in the buffer"
> 
> > The former sounds more useful, IMO.  I don't want to mess up my strings
> > just to have pretty source code
> 
> Filling strings in code would be useful, but isn't that a separate,
> don't-break-my-strings feature?

Not necessarily.  I frequently fill stuff in my code, and don't want
to use a separate command if the region I fill includes strings (or
comments, or something other that needs special filling behavior).

> Historically, the point of text justification is to make text fit on a
> screen.  For example, the documentation for fill-region refers to
> columns, which are features of buffers:
> 
>     Column beyond which automatic line-wrapping should happen.
> 
> Auto-fill-mode is consistent:
> 
>     inserting a space at a column beyond current-fill-column
>     automatically breaks the line
> 
> In a grand sweep, the manual explains what needs to fit where:
> 
>     “Filling” text means breaking it up into lines that fit a specified
>     width.
> 
> Section 26.6.2 ("Explicit Fill Commands") is even more, well, explicit:
> 
>     The command ‘M-q’ (‘fill-paragraph’) “fills” the current paragraph.
>     It redistributes the line breaks within the paragraph, and deletes
>     any excess space and tab characters occurring within the paragraph,
>     in such a way that the lines end up fitting within a certain maximum
>     width.
> 
> How text shows on a screen is clearly a central feature.  The manual
> continues:
> 
>     The maximum line width for filling is specified by the buffer-local
>     variable ‘fill-column’.  The default value (*note Locals::) is 70.
>     The easiest way to set ‘fill-column’ in the current buffer is to use
>     the command ‘C-x f’ (‘set-fill-column’).  [...]  Note that, by its
>     very nature, ‘fill-column’ is measured in column units; the actual
>     position of that column on a graphical display depends on the font
>     being used.  In particular, using variable-pitch fonts will cause
>     the ‘fill-column’ occupy different horizontal positions on display
>     in different lines.
> 
> In my view, the string interpretation calls for a different, though
> related feature.

You are quoting text which talks about the _default_ filling.  The
default filling is tailored to "uniform" text, i.e. really to Text
mode and its descendants.

However, Emacs lets major modes customize filling as appropriate for
the mode, by defining mode-specific filling functions.  Which is what
happens in this case: lisp-mode.el defines a fill-paragraph function
that is specific to Lisp modes.  It is completely legitimate for such
mode-specific functions to special-case strings inside code and do
something special about that.

So I don't see how what we do now is against the spirit of filling.

(Btw, I think it's high time we closed that bug, since Emacs 28.2 was
released long ago.)