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

[Maxim Cournoyer]

Hello,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

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

I agree that having a single way to 'fill text/code/whatever' is nice.

[...]

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

Maybe it doesn't in general, but in the case of Guix packages, it's
strikingly odd compared to the past behavior which was respecting the
fill-column in a long multi-line string (refer to the original issue I
had detailed in this thread for an example).

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

It's a change of behavior introduced in version 28 that apparently
doesn't make unanimity (though perhaps noticed mostly by Guix
developers, where the use of the multi-line strings for package
descriptions makes this issue very visible and annoying); the GNU Guix
project has been carrying this in its .dir-locals.el file, which simply
reverts to the old behavior before commit 9bf367e1848:

--8<---------------cut here---------------start------------->8---
   ;; Emacs 28 changed the behavior of 'lisp-fill-paragraph', which causes the
   ;; first line of package descriptions to extrude past 'fill-column', and
   ;; somehow that is deemed more correct upstream (see:
   ;; https://issues.guix.gnu.org/56197).
   (eval . (progn
             (require 'lisp-mode)
             (defun emacs27-lisp-fill-paragraph (&optional justify)
               (interactive "P")
               (or (fill-comment-paragraph justify)
                   (let ((paragraph-start
                          (concat paragraph-start
                                  "\\|\\s-*\\([(;\"]\\|\\s-:\\|`(\\|#'(\\)"))
                         (paragraph-separate
                          (concat paragraph-separate "\\|\\s-*\".*[,\\.]$"))
                         (fill-column (if (and (integerp 
emacs-lisp-docstring-fill-column)
                                               (derived-mode-p 
'emacs-lisp-mode))
                                          emacs-lisp-docstring-fill-column
                                        fill-column)))
                     (fill-paragraph justify))
                   ;; Never return nil.
                   t))
             (setq-local fill-paragraph-function 
#'emacs27-lisp-fill-paragraph)))
--8<---------------cut here---------------end--------------->8---

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?

Happy New Year,

-- 
Maxim