lisp-fill-paragraph behavior changed in Emacs 28

  • Done
  • quality assurance status badge
Details
6 participants
  • Eli Zaretskii
  • Felix Lechner
  • Lars Ingebrigtsen
  • Maxim Cournoyer
  • Stefan Kangas
  • Stefan Kangas
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal

Debbugs page

Maxim Cournoyer wrote 3 years ago
28.1; lisp-fill-paragraph result regressed with Emacs 28
(address . bug-gnu-emacs@gnu.org)
87zgi2xcgm.fsf@gmail.com
Hi,

After updating from Emacs 27 to Emacs 28 via GNU Guix, I noticed the
following change in behavior while attempting to indent a blob of text
in a Guix package definition (Scheme source):

;; Emacs 27
(description "IBus-Anthy is an engine for the input bus \"IBus\"). It
adds the Anthy Japanese language input method to IBus. Because most graphical
applications allow text input via IBus, installing this package will enable
Japanese language input in most graphical applications.")

;; Emacs 28
(description "IBus-Anthy is an engine for the input bus \"IBus\"). It adds the Anthy
Japanese language input method to IBus. Because most graphical applications
allow text input via IBus, installing this package will enable Japanese
language input in most graphical applications.")

I traced it down to commit 9bf367e1848:

Improve filling of Emacs Lisp doc strings
* lisp/emacs-lisp/lisp-mode.el (lisp-fill-paragraph): When filling
a Lisp string, try to avoid filling bits that follow it
(bug#28937).

Simply commenting out the newly added block, evaluating the defun and
running it on my example reverts to the previous correct behavior.

Thanks,

Maxim

---

In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Guix System

Configured using:
'configure
CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
--prefix=/gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1
--enable-fast-install --with-modules --with-cairo
--disable-build-details'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM
GTK3 ZLIB

Important settings:
value of $EMACSLOADPATH: /home/maxim/.guix-profile/share/emacs/site-lisp:/gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp
value of $LANG: en_US.utf8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix

Major mode: Debbugs

Minor modes in effect:
TeX-PDF-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
pyvenv-mode: t
shell-dirtrack-mode: t
yas-global-mode: t
yas-minor-mode: t
emms-mode-line-mode: t
emms-playing-time-display-mode: t
emms-playing-time-mode: t
ws-butler-global-mode: t
ws-butler-mode: t
counsel-mode: t
ivy-mode: t
global-so-long-mode: t
recentf-mode: t
global-company-mode: t
company-mode: t
electric-pair-mode: t
savehist-mode: t
winner-mode: t
display-time-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t

Load-path shadows:
~/.emacs.d/elisp/logview hides /gnu/store/bcbypx424n5xa6xlzlgz6zb3p6acpdcw-emacs-logview-0.14/share/emacs/site-lisp/logview-0.14/logview
/gnu/store/wy0d51sns5ivqqxrrcrw5ycg4qqdjcza-emacs-transient-0.3.7/share/emacs/site-lisp/transient-0.3.7/transient hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/transient
/gnu/store/r8vl0prsvj60c341il66ncavg0mvh9wc-emacs-xref-1.4.1/share/emacs/site-lisp/xref-1.4.1/xref hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/progmodes/xref
/gnu/store/3nqi6i7lhwd972y9w3xvswjz01v346gp-emacs-project-0.8.1/share/emacs/site-lisp/project-0.8.1/project hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/progmodes/project
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-texinfo hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-texinfo
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-publish hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-publish
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-org hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-org
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-odt hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-odt
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-md hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-md
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-man hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-man
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-latex hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-latex
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-koma-letter hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-koma-letter
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-icalendar hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-icalendar
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-html hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-html
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-beamer hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-beamer
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ox-ascii hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ox-ascii
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-timer hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-timer
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-table hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-table
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-src hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-src
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-refile hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-refile
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-protocol hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-protocol
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-plot hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-plot
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-pcomplete hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-pcomplete
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-num hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-num
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-mouse hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-mouse
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-mobile hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-mobile
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-macs hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-macs
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-macro hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-macro
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-loaddefs hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-loaddefs
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-list hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-list
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-lint hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-lint
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-keys hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-keys
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-inlinetask hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-inlinetask
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-indent hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-indent
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-id hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-id
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-habit hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-habit
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-footnote hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-footnote
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-goto hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-goto
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-feed hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-feed
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-faces hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-faces
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-entities hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-entities
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-element hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-element
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-duration hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-duration
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-ctags hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-ctags
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-compat hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-compat
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-colview hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-colview
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-clock hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-clock
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-capture hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-capture
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-attach hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-attach
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-archive hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-archive
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-agenda hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-agenda
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-bibtex hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-bibtex
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-bbdb hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-bbdb
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/oc hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/oc
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/oc-csl hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/oc-csl
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/oc-basic hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/oc-basic
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-tangle hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-tangle
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-sql hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-sql
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-shell hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-shell
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-ruby hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-ruby
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-python hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-python
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-octave hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-octave
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-lua hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-lua
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-lilypond hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-lilypond
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-julia hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-julia
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-java hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-java
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-haskell hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-haskell
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-gnuplot hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-gnuplot
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-exp hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-exp
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-core hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-core
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-comint hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-comint
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-R hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-R
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-C hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-C
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-tempo hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-tempo
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-version hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-version
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-install hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-install
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-datetree hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-datetree
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-crypt hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-crypt
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/org-attach-git hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/org-attach-git
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-w3m hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-w3m
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-rmail hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-rmail
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-mhe hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1
This message was truncated. Download the full message here.
Lars Ingebrigtsen wrote 3 years ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 56197@debbugs.gnu.org)
87y1xlj6wn.fsf@gnus.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (6 lines)
> ;; Emacs 28
> (description "IBus-Anthy is an engine for the input bus \"IBus\"). It adds the Anthy
> Japanese language input method to IBus. Because most graphical applications
> allow text input via IBus, installing this package will enable Japanese
> language input in most graphical applications.")

[...]

Toggle quote (3 lines)
> Simply commenting out the newly added block, evaluating the defun and
> running it on my example reverts to the previous correct behavior.

I'm not sure the previous behaviour was any more correct. 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", which is wrong in most
contexts.

So I don't know. Anybody have an opinion?

--
(domestic pets only, the antidote for overdose, milk.)
Eli Zaretskii wrote 3 years ago
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
834k08c3se.fsf@gnu.org
Toggle quote (25 lines)
> Cc: 56197@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 25 Jun 2022 13:53:44 +0200
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
> > ;; Emacs 28
> > (description "IBus-Anthy is an engine for the input bus \"IBus\"). It adds the Anthy
> > Japanese language input method to IBus. Because most graphical applications
> > allow text input via IBus, installing this package will enable Japanese
> > language input in most graphical applications.")
>
> [...]
>
> > Simply commenting out the newly added block, evaluating the defun and
> > running it on my example reverts to the previous correct behavior.
>
> I'm not sure the previous behaviour was any more correct. 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", which is wrong in most
> contexts.
>
> So I don't know. Anybody have an opinion?

I actually don't understand what kind of "Lisp code" is the above
snippet. It doesn't look to me as valid Lisp code. So there's no
criteria for judging the correctness here, it seems.
Lars Ingebrigtsen wrote 3 years ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
874k08kj31.fsf@gnus.org
Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (4 lines)
> I actually don't understand what kind of "Lisp code" is the above
> snippet. It doesn't look to me as valid Lisp code. So there's no
> criteria for judging the correctness here, it seems.

It's just (foo "... very long multiline string"). I was also confused,
because the string looked very odd -- it has a ) inside the string, but
no (, but that's not really relevant.

--
(domestic pets only, the antidote for overdose, milk.)
Lars Ingebrigtsen wrote 3 years ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
87y1xkj4co.fsf@gnus.org
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (4 lines)
> It's just (foo "... very long multiline string"). I was also confused,
> because the string looked very odd -- it has a ) inside the string, but
> no (, but that's not really relevant.

Oh, hang on -- there definitely is a bug here. Here's a better test case:

(foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a very long line This is a very long line This is a very long line This is a very long line This is a very long line.
And another long line.")

`M-q' in the first line does nothing, and it should. I'll have a look.

--
(domestic pets only, the antidote for overdose, milk.)
Lars Ingebrigtsen wrote 3 years ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
87tu88j3tf.fsf@gnus.org
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (2 lines)
> `M-q' in the first line does nothing, and it should. I'll have a look.

I've now fixed that, but the question still remains -- should

(foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a very long line This is a very long line This is a very long line This")

be filled as

(foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a very long line This is a very long line This is a very
long line This")

(i.e., fill the string using fill-column, or

(foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a
very long line This is a very long line This is a very long line This")

(i.e., fill the text as is in the buffer).

--
(domestic pets only, the antidote for overdose, milk.)
Maxim Cournoyer wrote 3 years ago
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)
874k06zxar.fsf@gmail.com
Hello,

Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (21 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> ;; Emacs 28
>> (description "IBus-Anthy is an engine for the input bus \"IBus\"). It adds the Anthy
>> Japanese language input method to IBus. Because most graphical applications
>> allow text input via IBus, installing this package will enable Japanese
>> language input in most graphical applications.")
>
> [...]
>
>> Simply commenting out the newly added block, evaluating the defun and
>> running it on my example reverts to the previous correct behavior.
>
> I'm not sure the previous behaviour was any more correct. 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", which is wrong in most
> contexts.
>
> So I don't know. Anybody have an opinion?

Apologies if my previous example lacked too much context and confused
more than helped. Here's another example, where I just experienced the
problem after revamping the GNU Guix 'font-abattis-cantarrel' package
definition:

Toggle snippet (32 lines)
(define-public font-abattis-cantarell
(package
(name "font-abattis-cantarell")
(version "0.303")
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://gitlab.gnome.org/GNOME/cantarell-fonts")
(commit (string-append "v" version))))
(file-name (git-file-name name version))
(sha256
(base32
"1d1ay0fdqchk0wa5yqxis2c98imvzsbbd2kjv0x8sk4fm419847b"))))
(build-system meson-build-system)
(arguments
(list #:configure-flags #~(list "-Dbuildstatics=true")))
(native-inputs
(list gettext-minimal
psautohint
python
python-cffsubr
python-fontmath
python-statmake
python-ufo2ft))
(home-page "https://wiki.gnome.org/Projects/CantarellFonts")
(synopsis "Cantarell sans-serif typeface")
(description "The Cantarell font family is a contemporary Humanist sans-serif designed for
on-screen reading. It is used by GNOME@tie{}3. This package contains both
the non-variable as well as the variable versions of the font.")
(license license:silofl1.1)))
This is a Scheme sexp extracted from the (gnu packages fonts) Guile
module. Hitting `lisp-fill-paragraph' (M-q) causes the above
indentation, where the first line of the description extends past the
`fill-column' value.

I hope that helps,

Thanks!

Maxim
Stefan Kangas wrote 3 years ago
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
CADwFkmmR8Edn7k33WUj6ytMx_VqqRce+UcVE6NVfXt9daNdauQ@mail.gmail.com
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (16 lines)
> I've now fixed that, but the question still remains -- should
>
> (foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a very long line This is a very long line This is a very long line This")
>
> be filled as
>
> (foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a very long line This is a very long line This is a very
> long line This")
>
> (i.e., fill the string using fill-column, or
>
> (foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot-foo-bar-zot "This is a
> very long line This is a very long line This is a very long line This")
>
> (i.e., fill the text as is in the buffer).

The former sounds more useful, IMO. I don't want to mess up my strings
just to have pretty source code; I can make such adjustments manually
when I need to.
Lars Ingebrigtsen wrote 3 years ago
(name . Stefan Kangas)(address . stefan@marxist.se)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
87r136cx9j.fsf@gnus.org
Stefan Kangas <stefan@marxist.se> writes:

Toggle quote (4 lines)
> The former sounds more useful, IMO. I don't want to mess up my strings
> just to have pretty source code; I can make such adjustments manually
> when I need to.

So the votes are in, and I guess we'll keep the current behaviour in
Emacs 29, and I'm therefore closing this bug report.

--
(domestic pets only, the antidote for overdose, milk.)
Lars Ingebrigtsen wrote 3 years ago
(name . Stefan Kangas)(address . stefan@marxist.se)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)
87mtducx7g.fsf@gnus.org
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (3 lines)
> So the votes are in, and I guess we'll keep the current behaviour in
> Emacs 29, and I'm therefore closing this bug report.

Or -- perhaps it should be backported to Emacs 28 -- but not right now,
since the release is impending. So I'll keep this open until after
Emacs 28.2, I think.

--
(domestic pets only, the antidote for overdose, milk.)
Lars Ingebrigtsen wrote 3 years ago
control message for bug #56197
(address . control@debbugs.gnu.org)
87letecx75.fsf@gnus.org
tags 56197 + pending
quit
Maxim Cournoyer wrote 3 years ago
Re: bug#56197: 28.1; lisp-fill-para graph result regressed with Emacs 28
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Stefan Kangas)(address . stefan@marxist.se)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)
5742C214-5A0B-45B7-B9BA-D1E907C79A2B@gmail.com
On June 30, 2022 5:32:08 AM EDT, Lars Ingebrigtsen <larsi@gnus.org> wrote:
Toggle quote (10 lines)
>Stefan Kangas <stefan@marxist.se> writes:
>
>> The former sounds more useful, IMO. I don't want to mess up my strings
>> just to have pretty source code; I can make such adjustments manually
>> when I need to.
>
>So the votes are in, and I guess we'll keep the current behaviour in
>Emacs 29, and I'm therefore closing this bug report.
>

Just to make sure, this means the paragraph filling behavior seen in the examples I shared would be unchanged, and different from that in Emacs 27 and earlier, correct?

To me, the previous behavior was useful; is there a way to configure Emacs to behave that way with Emacs 28?

Thank you!

Maxim
Hi,
Lars Ingebrigtsen wrote 3 years ago
Re: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(name . Eli Zaretskii)(address . eliz@gnu.org)(name . Stefan Kangas)(address . stefan@marxist.se)(address . 56197@debbugs.gnu.org)
87h741yzhd.fsf@gnus.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (4 lines)
> Just to make sure, this means the paragraph filling behavior seen in
> the examples I shared would be unchanged, and different from that in
> Emacs 27 and earlier, correct?

Yup.

Toggle quote (3 lines)
> To me, the previous behavior was useful; is there a way to configure
> Emacs to behave that way with Emacs 28?

I guess you can set fill-paragraph-function to a function that does what
you want?

--
(domestic pets only, the antidote for overdose, milk.)
Felix Lechner wrote 3 months ago
28.1; lisp-fill-paragraph result regressed with Emacs 28
(address . 56197@debbugs.gnu.org)(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(name . Stefan Kangas)(address . stefankangas@gmail.com)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87bjwzr027.fsf@lease-up.com
Hi everyone,

Toggle quote (10 lines)
> 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?

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.

Maybe there could be (setq fill-strings-instead-of-text t) ? Thanks!

Kind regards
Felix
Eli Zaretskii wrote 3 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
86v7v7ynf0.fsf@gnu.org
Toggle quote (19 lines)
> 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).

Toggle quote (40 lines)
> 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.)
Stefan Kangas wrote 3 months ago
Re: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . maxim.cournoyer@gmail.com)(address . 56197-done@debbugs.gnu.org)
CADwFkmm0zmNn2FjAbv4PscNDcuO0fHgn+AS01buKpAhdJ8QxXQ@mail.gmail.com
Lars Ingebrigtsen <larsi@gnus.org> writes:

Toggle quote (9 lines)
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So the votes are in, and I guess we'll keep the current behaviour in
>> Emacs 29, and I'm therefore closing this bug report.
>
> Or -- perhaps it should be backported to Emacs 28 -- but not right now,
> since the release is impending. So I'll keep this open until after
> Emacs 28.2, I think.

Emacs 28 was released on 2022-04-04, so I'm closing this bug now.
Closed
Maxim Cournoyer wrote 3 months ago
Re: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87seq8tm2f.fsf@gmail.com
Hello,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (7 lines)
>> 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.

[...]

Toggle quote (13 lines)
> 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).

Toggle quote (3 lines)
> (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:

Toggle snippet (24 lines)
;; 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)))

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
Maxim Cournoyer wrote 3 months ago
Re: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Stefan Kangas)(address . stefankangas@gmail.com)(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197-done@debbugs.gnu.org)
877c7ktkuj.fsf@gmail.com
Hi Stefan,

Stefan Kangas <stefankangas@gmail.com> writes:

Toggle quote (13 lines)
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> So the votes are in, and I guess we'll keep the current behaviour in
>>> Emacs 29, and I'm therefore closing this bug report.
>>
>> Or -- perhaps it should be backported to Emacs 28 -- but not right now,
>> since the release is impending. So I'll keep this open until after
>> Emacs 28.2, I think.
>
> Emacs 28 was released on 2022-04-04, so I'm closing this bug now.

The issue says "regressed in", not "affects only", for what it's worth.
The regression/change in behavior still applies to the current release
of Emacs.

--
Thanks,
Maxim
Closed
Eli Zaretskii wrote 3 months ago
Re: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
86o70wurf9.fsf@gnu.org
Toggle quote (10 lines)
> 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.

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.
Eli Zaretskii wrote 3 months ago
Re: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . stefankangas@gmail.com)(address . 56197@debbugs.gnu.org)
86msggurca.fsf@gnu.org
Toggle quote (26 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
> 56197-done@debbugs.gnu.org
> Date: Sat, 28 Dec 2024 14:52:52 +0900
>
> Hi Stefan,
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Lars Ingebrigtsen <larsi@gnus.org> writes:
> >
> >> Lars Ingebrigtsen <larsi@gnus.org> writes:
> >>
> >>> So the votes are in, and I guess we'll keep the current behaviour in
> >>> Emacs 29, and I'm therefore closing this bug report.
> >>
> >> Or -- perhaps it should be backported to Emacs 28 -- but not right now,
> >> since the release is impending. So I'll keep this open until after
> >> Emacs 28.2, I think.
> >
> > Emacs 28 was released on 2022-04-04, so I'm closing this bug now.
>
> The issue says "regressed in", not "affects only", for what it's worth.
> The regression/change in behavior still applies to the current release
> of Emacs.

We don't agree it's a regression, as shown in the discussion of this
bug.
Stefan Kangas wrote 3 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(name . Lars Ingebrigtsen)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)
CADwFkmme2o1Q+afE-qkapmuqDfZJHC54vFzaS9_Fjz0OX_cfdA@mail.gmail.com
reopen 56197
thanks

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (10 lines)
> Hi Stefan,
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Emacs 28 was released on 2022-04-04, so I'm closing this bug now.
>
> The issue says "regressed in", not "affects only", for what it's worth.
> The regression/change in behavior still applies to the current release
> of Emacs.

Sorry for misunderstanding. I'm reopening the bug with this message.
Maxim Cournoyer wrote 3 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . stefankangas@gmail.com)(address . 56197@debbugs.gnu.org)
871pxrsvx5.fsf@gmail.com
Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (9 lines)
>> > Emacs 28 was released on 2022-04-04, so I'm closing this bug now.
>>
>> The issue says "regressed in", not "affects only", for what it's worth.
>> The regression/change in behavior still applies to the current release
>> of Emacs.
>
> We don't agree it's a regression, as shown in the discussion of this
> bug.

We can call it 'change in behavior'; I agree in most cases the new
behavior is probably good. I don't see us being in disagreement; I
think Felix and I are pointing that the change has impacted negatively
at least one use case, and we're exploring ideas for a better solution
to that than pasting the previous copy in a project's .dir-locals.el
file (I'll explain in your other question why I see this as suboptimal).

--
Thanks,
Maxim
Maxim Cournoyer wrote 3 months ago
control message for bug #56197
(address . control@debbugs.gnu.org)
87zfkfrh98.fsf@gmail.com
retitle 56197 lisp-fill-paragraph behavior changed in Emacs 28
quit
Maxim Cournoyer wrote 3 months ago
Re: 28.1; lisp-fill-paragraph result regressed with Emacs 28
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87ttanrg9h.fsf@gmail.com
Hello,

Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (15 lines)
>> 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.

Toggle quote (10 lines)
> 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
Maxim Cournoyer wrote 2 months ago
Re: bug#56197: lisp-fill-paragraph behavior changed in Emacs 28
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87v7uuevq1.fsf_-_@gmail.com
Hi Eli et al.,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Toggle quote (9 lines)
>> 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 tried fixing this generally, as it seems to me that something in
lisp-mode should be meet the needs of all lisp-derived languages such as
Scheme and not just Elisp. I first added two tests, one of which
ensures no regression to the original bug that lead to this current
behavioral change (bug#28937) and the other one that should pass once
the issue reported here (bug#56197) is resolved.

The last patch is a WIP that didn't work; I was hoping that inserting
spaces corresponding to the width of the indent in the narrowed string
would cause the indent to be preserved only for the first line. I don't
have other ideas at the moment; I'd appreciate if someone could tip in.
From aacf65440070df2ba356af1d118a50993fc8f865 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Mon, 30 Dec 2024 12:02:36 +0900
Subject: [PATCH 1/3] test/lisp: Add new test for filling behavior change.

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 (see bug#56197).

* test/lisp/emacs-lisp/lisp-mode-tests.el
(lisp-fill-paragraph-respects-fill-column): New test.
---
test/lisp/emacs-lisp/lisp-mode-tests.el | 27 +++++++++++++++++++++++++
1 file changed, 27 insertions(+)

Toggle diff (42 lines)
diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el
index da02be65d03..9a2b1ea4654 100644
--- a/test/lisp/emacs-lisp/lisp-mode-tests.el
+++ b/test/lisp/emacs-lisp/lisp-mode-tests.el
@@ -308,6 +308,33 @@ lisp-indent-defun
(indent-region (point-min) (point-max))
(should (equal (buffer-string) orig)))))
+
+;;; Filling
+
+(ert-deftest lisp-fill-paragraph-respects-fill-column ()
+ "Test bug#56197 -- more specifically, validate that a leading indentation
+for a string is preserved in the filled string."
+ (with-temp-buffer
+ ;; The following is a contrived example that demonstrates the
+ ;; fill-column problem when the string to fill is indented.
+ (insert "\
+\(defun test ()
+ \"This is a long string which is indented by a considerable value,
+causing it to protrude from the configured `fill-column' since
+lisp-fill-paragraph was refactored in version 28.\"
+ (message \"Hi!\"))")
+ (emacs-lisp-mode)
+ (search-backward "This is a long string")
+ (fill-paragraph) ;function under test
+ (goto-char (point-min))
+ (let ((i 1)
+ (lines-count (count-lines (point-min) (point-max))))
+ (while (< i lines-count)
+ (beginning-of-line i)
+ (end-of-line)
+ (should (<= (current-column) fill-column))
+ (setq i (1+ i))))))
+
;;; Fontification

base-commit: e32484547d0813665334bfd34b741492dde0d374
--
2.46.0
From e5685497111ef71e57948f023f8d2a03647c3d69 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Mon, 30 Dec 2024 14:26:46 +0900
Subject: [PATCH 2/3] test/lisp: Add a test checking docstring boundaries when
filling.

* test/lisp/emacs-lisp/lisp-mode-tests.el
(lisp-fill-paragraph-docstring-boundaries): New test.
---
test/lisp/emacs-lisp/lisp-mode-tests.el | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

Toggle diff (32 lines)
diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el
index 9a2b1ea4654..eac2763c595 100644
--- a/test/lisp/emacs-lisp/lisp-mode-tests.el
+++ b/test/lisp/emacs-lisp/lisp-mode-tests.el
@@ -311,6 +311,25 @@ lisp-indent-defun
;;; Filling
+(ert-deftest lisp-fill-paragraph-docstring-boundaries ()
+ "Test bug#28937, ensuring filling the docstring filled is properly
+bounded."
+ (with-temp-buffer
+ (insert "\
+(defun test ()
+ \"This is a test docstring.
+Here is some more text.\"
+ 1
+ 2
+ 3
+ 4
+ 5)")
+ (let ((correct (buffer-string)))
+ (emacs-lisp-mode)
+ (search-backward "This is a test docstring")
+ (fill-paragraph) ;function under test
+ (should (equal (buffer-string) correct)))))
+
(ert-deftest lisp-fill-paragraph-respects-fill-column ()
"Test bug#56197 -- more specifically, validate that a leading indentation
for a string is preserved in the filled string."
--
2.46.0
From 5bc5de2fc6f7783b0cd71c5945755fc98431aa60 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Tue, 31 Dec 2024 10:18:30 +0900
Subject: [PATCH 3/3] wip: work on solution

---
lisp/emacs-lisp/lisp-mode.el | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)

Toggle diff (75 lines)
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index d0c32d238bc..6c6d88f73a5 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -1,6 +1,6 @@
;;; lisp-mode.el --- Lisp mode, and its idiosyncratic commands -*- lexical-binding:t -*-
-;; Copyright (C) 1985-1986, 1999-2024 Free Software Foundation, Inc.
+;; Copyright (C) 1985-1986, 1999-2025 Free Software Foundation, Inc.
;; Maintainer: emacs-devel@gnu.org
;; Keywords: lisp, languages
@@ -1480,30 +1480,34 @@ lisp-fill-paragraph
(derived-mode-p 'emacs-lisp-mode))
emacs-lisp-docstring-fill-column
fill-column)))
- (let ((ppss (syntax-ppss))
- (start (point))
- ;; Avoid recursion if we're being called directly with
- ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
- (fill-paragraph-function t))
+ (let* ((ppss (syntax-ppss))
+ (start (point))
+ ;; Avoid recursion if we're being called directly with
+ ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
+ (fill-paragraph-function t)
+ (string-start (ppss-comment-or-string-start ppss))
+ (indent (save-excursion
+ (goto-char string-start)
+ (current-column))))
(save-excursion
(save-restriction
;; If we're not inside a string, then do very basic
;; filling. This avoids corrupting embedded strings in
;; code.
- (if (not (ppss-comment-or-string-start ppss))
+ (if (not string-start)
(lisp--fill-line-simple)
;; If we're in a string, then narrow (roughly) to that
;; string before filling. This avoids filling Lisp
;; statements that follow the string.
(when (ppss-string-terminator ppss)
- (goto-char (ppss-comment-or-string-start ppss))
+ (goto-char string-start)
;; The string may be unterminated -- in that case, don't
;; narrow.
(when (ignore-errors
(progn
(forward-sexp 1)
t))
- (narrow-to-region (1+ (ppss-comment-or-string-start ppss))
+ (narrow-to-region (1+ string-start)
(1- (point)))))
;; Move back to where we were.
(goto-char start)
@@ -1516,7 +1520,16 @@ lisp-fill-paragraph
(goto-char (point-min))
(forward-line 1)
(narrow-to-region (point) (point-max))))
- (fill-paragraph justify)))))))
+ ;; Insert spaces to reproduce the same leading indent
+ ;; for the string inside the narrowed region, to avoid
+ ;; bug#56197.
+ (save-excursion
+ (goto-char (point-min))
+ (insert (make-string indent ?\s)))
+ (fill-paragraph justify)
+ (save-excursion ;clean up
+ (goto-char (point-min))
+ (delete-char indent))))))))
;; Never return nil.
t)
--
2.46.0
If that's not easily fixable, perhaps I'll submit a patch to the paredit
project so that they stop relying on lisp-paragraph-fill [0] and instead
use the default (which is fill-paragraph). That's how I came to notice
this behavior change in GNU Guix, which is written in Scheme; using
scheme-mode doesn't exhibit the issue since it's just using
fill-paragraph.


--
Thanks,
Maxim
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87r05ievib.fsf@gmail.com
Hi again,

[...]

Toggle quote (7 lines)
> If that's not easily fixable, perhaps I'll submit a patch to the paredit
> project so that they stop relying on lisp-paragraph-fill [0] and instead
> use the default (which is fill-paragraph). That's how I came to notice
> this behavior change in GNU Guix, which is written in Scheme; using
> scheme-mode doesn't exhibit the issue since it's just using
> fill-paragraph.

Actually, it seems scheme-mode at least in Emacs 29.4 does make use of
lisp-fill-paragraph, so should exhibit the same behavior/problem:
c.f. circa line 178 of scheme.el:

Toggle snippet (3 lines)
(setq-local fill-paragraph-function 'lisp-fill-paragraph)

--
Thanks,
Maxim
Maxim Cournoyer wrote 2 months ago
[PATCH] lisp: Introduce lisp-fill-paragraph-as-displayed option.
(address . 56197@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20250104130343.4801-1-maxim.cournoyer@gmail.com
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.

* lisp/emacs-lisp/lisp-mode.el (lisp-fill-paragraph-as-displayed): New
variable.
(lisp-fill-paragraph): Honor it, by avoiding the logic narrow to strings
before applying fill-paragraph.
* test/lisp/emacs-lisp/lisp-mode-tests.el
(lisp-fill-paragraph-respects-fill-column): Test it.
(lisp-fill-paragraph-docstring-boundaries): New test, as a safeguard to
avoid regressions.

Fixes: bug#56197
---
lisp/emacs-lisp/lisp-mode.el | 74 ++++++++++++++-----------
test/lisp/emacs-lisp/lisp-mode-tests.el | 47 ++++++++++++++++
2 files changed, 90 insertions(+), 31 deletions(-)

Toggle diff (164 lines)
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index d0c32d238bc..cc9f6f51cb5 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -1,6 +1,6 @@
;;; lisp-mode.el --- Lisp mode, and its idiosyncratic commands -*- lexical-binding:t -*-
-;; Copyright (C) 1985-1986, 1999-2024 Free Software Foundation, Inc.
+;; Copyright (C) 1985-1986, 1999-2025 Free Software Foundation, Inc.
;; Maintainer: emacs-devel@gnu.org
;; Keywords: lisp, languages
@@ -1431,6 +1431,16 @@ emacs-lisp-docstring-fill-column
:group 'lisp
:version "30.1")
+(defcustom lisp-fill-paragraph-as-displayed nil
+ "Fill paragraphs as displayed in the buffer, preserving surrounding
+context such as the leading indentation. This is useful if respecting
+`fill-column' is more important than avoiding surrounding code from
+being filled, and makes `lisp-fill-paragraph' behave as it used to in
+Emacs 27 and prior versions."
+ :type 'boolean
+ :group 'lisp
+ :version "31.0")
+
(defun lisp-fill-paragraph (&optional justify)
"Like \\[fill-paragraph], but handle Emacs Lisp comments and docstrings.
If any of the current line is a comment, fill the comment or the
@@ -1480,42 +1490,44 @@ lisp-fill-paragraph
(derived-mode-p 'emacs-lisp-mode))
emacs-lisp-docstring-fill-column
fill-column)))
- (let ((ppss (syntax-ppss))
- (start (point))
- ;; Avoid recursion if we're being called directly with
- ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
- (fill-paragraph-function t))
+ (let* ((ppss (syntax-ppss))
+ (start (point))
+ ;; Avoid recursion if we're being called directly with
+ ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
+ (fill-paragraph-function t)
+ (string-start (ppss-comment-or-string-start ppss)))
(save-excursion
(save-restriction
;; If we're not inside a string, then do very basic
;; filling. This avoids corrupting embedded strings in
;; code.
- (if (not (ppss-comment-or-string-start ppss))
+ (if (not string-start)
(lisp--fill-line-simple)
- ;; If we're in a string, then narrow (roughly) to that
- ;; string before filling. This avoids filling Lisp
- ;; statements that follow the string.
- (when (ppss-string-terminator ppss)
- (goto-char (ppss-comment-or-string-start ppss))
- ;; The string may be unterminated -- in that case, don't
- ;; narrow.
- (when (ignore-errors
- (progn
- (forward-sexp 1)
- t))
- (narrow-to-region (1+ (ppss-comment-or-string-start ppss))
- (1- (point)))))
- ;; Move back to where we were.
- (goto-char start)
- ;; We should fill the first line of a string
- ;; separately (since it's usually a doc string).
- (if (= (line-number-at-pos) 1)
- (narrow-to-region (line-beginning-position)
- (line-beginning-position 2))
- (save-excursion
- (goto-char (point-min))
- (forward-line 1)
- (narrow-to-region (point) (point-max))))
+ (unless lisp-fill-paragraph-as-displayed
+ ;; If we're in a string, then narrow (roughly) to that
+ ;; string before filling. This avoids filling Lisp
+ ;; statements that follow the string.
+ (when (ppss-string-terminator ppss)
+ (goto-char string-start)
+ ;; The string may be unterminated -- in that case, don't
+ ;; narrow.
+ (when (ignore-errors
+ (progn
+ (forward-sexp 1)
+ t))
+ (narrow-to-region (1+ string-start)
+ (1- (point)))))
+ ;; Move back to where we were.
+ (goto-char start)
+ ;; We should fill the first line of a string
+ ;; separately (since it's usually a doc string).
+ (if (= (line-number-at-pos) 1)
+ (narrow-to-region (line-beginning-position)
+ (line-beginning-position 2))
+ (save-excursion
+ (goto-char (point-min))
+ (forward-line 1)
+ (narrow-to-region (point) (point-max)))))
(fill-paragraph justify)))))))
;; Never return nil.
t)
diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el
index da02be65d03..347b3d5b642 100644
--- a/test/lisp/emacs-lisp/lisp-mode-tests.el
+++ b/test/lisp/emacs-lisp/lisp-mode-tests.el
@@ -308,6 +308,53 @@ lisp-indent-defun
(indent-region (point-min) (point-max))
(should (equal (buffer-string) orig)))))
+
+;;; Filling
+
+(ert-deftest lisp-fill-paragraph-docstring-boundaries ()
+ "Test bug#28937, ensuring filling the docstring filled is properly
+bounded."
+ (with-temp-buffer
+ (insert "\
+(defun test ()
+ \"This is a test docstring.
+Here is some more text.\"
+ 1
+ 2
+ 3
+ 4
+ 5)")
+ (let ((correct (buffer-string)))
+ (emacs-lisp-mode)
+ (search-backward "This is a test docstring")
+ (fill-paragraph) ;function under test
+ (should (equal (buffer-string) correct)))))
+
+(ert-deftest lisp-fill-paragraph-as-displayed ()
+ "Test bug#56197 -- more specifically, validate that a leading indentation
+for a string is preserved in the filled string."
+ (let ((lisp-fill-paragraph-as-displayed t) ;option under test
+ (source "\
+'(description \"This is a very long string which is indented by a considerable value, causing it to
+protrude from the configured `fill-column' since
+lisp-fill-paragraph was refactored in version 28.\")"))
+ (with-temp-buffer
+ ;; The following is a contrived example that demonstrates the
+ ;; fill-column problem when the string to fill is indented.
+ (insert source)
+ (emacs-lisp-mode)
+ (search-backward "This is a very long string")
+ (fill-paragraph) ;function under test
+ (goto-char (point-min))
+ (message "%s" (buffer-substring-no-properties (point-min) (point-max)))
+ (let ((i 1)
+ (lines-count (count-lines (point-min) (point-max))))
+ (while (< i lines-count)
+ (beginning-of-line i)
+ (end-of-line)
+ (should (<= (current-column) fill-column))
+ (setq i (1+ i)))))))
+
;;; Fontification
--
2.46.0
Maxim Cournoyer wrote 2 months ago
control message for bug #56197
(address . control@debbugs.gnu.org)
87pll2enmv.fsf@gmail.com
tags 56197 + patch
quit
Eli Zaretskii wrote 2 months ago
Re: bug#56197: [PATCH] lisp: Introduce lisp-fill-paragraph-as-displayed option.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . felix.lechner@lease-up.com)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
86frlyd6d5.fsf@gnu.org
Toggle quote (9 lines)
> Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, eliz@gnu.org, larsi@gnus.org, felix.lechner@lease-up.com, stefankangas@gmail.com
> From: Maxim Cournoyer <maxim.cournoyer@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.

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?
Eli Zaretskii wrote 2 months ago
Re: bug#56197: lisp-fill-paragraph behavior changed in Emacs 28
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
86ed1id6a3.fsf@gnu.org
Toggle quote (26 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: larsi@gnus.org, 56197@debbugs.gnu.org, felix.lechner@lease-up.com,
> stefankangas@gmail.com
> Date: Sat, 04 Jan 2025 19:09:42 +0900
>
> >> 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 tried fixing this generally, as it seems to me that something in
> lisp-mode should be meet the needs of all lisp-derived languages such as
> Scheme and not just Elisp. I first added two tests, one of which
> ensures no regression to the original bug that lead to this current
> behavioral change (bug#28937) and the other one that should pass once
> the issue reported here (bug#56197) is resolved.
>
> The last patch is a WIP that didn't work; I was hoping that inserting
> spaces corresponding to the width of the indent in the narrowed string
> would cause the indent to be preserved only for the first line. I don't
> have other ideas at the moment; I'd appreciate if someone could tip in.

Since you submitted a new bug report about this issue, does that mean
these comments and the patches are no longer pertinent?
Eli Zaretskii wrote 2 months ago
(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
867c7ad5lc.fsf@gnu.org
Toggle quote (34 lines)
> Cc: larsi@gnus.org, 56197@debbugs.gnu.org, felix.lechner@lease-up.com,
> stefankangas@gmail.com
> Date: Sat, 04 Jan 2025 16:04:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> > Cc: larsi@gnus.org, 56197@debbugs.gnu.org, felix.lechner@lease-up.com,
> > stefankangas@gmail.com
> > Date: Sat, 04 Jan 2025 19:09:42 +0900
> >
> > >> 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 tried fixing this generally, as it seems to me that something in
> > lisp-mode should be meet the needs of all lisp-derived languages such as
> > Scheme and not just Elisp. I first added two tests, one of which
> > ensures no regression to the original bug that lead to this current
> > behavioral change (bug#28937) and the other one that should pass once
> > the issue reported here (bug#56197) is resolved.
> >
> > The last patch is a WIP that didn't work; I was hoping that inserting
> > spaces corresponding to the width of the indent in the narrowed string
> > would cause the indent to be preserved only for the first line. I don't
> > have other ideas at the moment; I'd appreciate if someone could tip in.
>
> Since you submitted a new bug report about this issue, does that mean
> these comments and the patches are no longer pertinent?

Sorry, I should have written "new patch", not "new bug report".
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87h662dmln.fsf@gmail.com
Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (5 lines)
>> Since you submitted a new bug report about this issue, does that mean
>> these comments and the patches are no longer pertinent?
>
> Sorry, I should have written "new patch", not "new bug report".

Yes, the last patch I've sent is no longer a WIP and addresses the issue
for me (while improving the coverage of the test suite). Please have a
look when time allows!

--
Thanks,
Maxim
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87ikqfcps8.fsf_-_@gmail.com
Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (15 lines)
>> Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, eliz@gnu.org,
>> larsi@gnus.org, felix.lechner@lease-up.com, stefankangas@gmail.com
>> From: Maxim Cournoyer <maxim.cournoyer@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.

Toggle quote (4 lines)
> 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!

--
Thanks,
Maxim
Eli Zaretskii wrote 2 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
86ikqfi2ws.fsf@gnu.org
Toggle quote (28 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: larsi@gnus.org, felix.lechner@lease-up.com, 56197@debbugs.gnu.org,
> stefankangas@gmail.com
> Date: Thu, 16 Jan 2025 14:04:55 +0900
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, eliz@gnu.org,
> >> larsi@gnus.org, felix.lechner@lease-up.com, stefankangas@gmail.com
> >> From: Maxim Cournoyer <maxim.cournoyer@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.

Toggle quote (7 lines)
> > 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.
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87msfn6kwv.fsf@gmail.com
Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (20 lines)
>> > 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.

Good point. The current behavior is probably useful when editing Emacs
Lisp, so I agree that setting this precisely for specific modes (such as
scheme-mode) instead probably makes more sense.

Toggle quote (7 lines)
> 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.

OK! I'll send a reworked version using defvar shortly. Thanks for the
thoughtful discussion!

--
Maxim
Maxim Cournoyer wrote 2 months ago
[PATCH v2] lisp: Introduce a `lisp-fill-paragraph-as-displayed' variable.
(address . 56197@debbugs.gnu.org)(address . eliz@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
20250119125230.11812-1-maxim.cournoyer@gmail.com
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 variable allowing opting out of this new behavior in specific
scenarios (such as when using the Scheme major mode, say).

* lisp/emacs-lisp/lisp-mode.el (lisp-fill-paragraph-as-displayed): New
variable.
(lisp-fill-paragraph): Honor it, by avoiding the logic narrow to strings
before applying fill-paragraph.
* test/lisp/emacs-lisp/lisp-mode-tests.el
(lisp-fill-paragraph-respects-fill-column): Test it.
(lisp-fill-paragraph-docstring-boundaries): New test, as a safeguard to
avoid regressions.

Fixes: bug#56197
---
Changes since v1: Use defvar, not defcustom + light rewordings of some
doc/comments

lisp/emacs-lisp/lisp-mode.el | 72 ++++++++++++++-----------
test/lisp/emacs-lisp/lisp-mode-tests.el | 47 ++++++++++++++++
2 files changed, 88 insertions(+), 31 deletions(-)

Toggle diff (162 lines)
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index d0c32d238bc..c55dd3c6528 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -1,6 +1,6 @@
;;; lisp-mode.el --- Lisp mode, and its idiosyncratic commands -*- lexical-binding:t -*-
-;; Copyright (C) 1985-1986, 1999-2024 Free Software Foundation, Inc.
+;; Copyright (C) 1985-1986, 1999-2025 Free Software Foundation, Inc.
;; Maintainer: emacs-devel@gnu.org
;; Keywords: lisp, languages
@@ -1431,6 +1431,14 @@ emacs-lisp-docstring-fill-column
:group 'lisp
:version "30.1")
+(defvar lisp-fill-paragraph-as-displayed nil
+ "This variable can be set to true to fill paragraphs as displayed in the
+buffer, preserving surrounding context such as the leading indentation.
+This is useful if respecting `fill-column' is more important than
+preventing surrounding code from being filled, and makes
+`lisp-fill-paragraph' behave as it used to in Emacs 27 and prior
+versions.")
+
(defun lisp-fill-paragraph (&optional justify)
"Like \\[fill-paragraph], but handle Emacs Lisp comments and docstrings.
If any of the current line is a comment, fill the comment or the
@@ -1480,42 +1488,44 @@ lisp-fill-paragraph
(derived-mode-p 'emacs-lisp-mode))
emacs-lisp-docstring-fill-column
fill-column)))
- (let ((ppss (syntax-ppss))
- (start (point))
- ;; Avoid recursion if we're being called directly with
- ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
- (fill-paragraph-function t))
+ (let* ((ppss (syntax-ppss))
+ (start (point))
+ ;; Avoid recursion if we're being called directly with
+ ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
+ (fill-paragraph-function t)
+ (string-start (ppss-comment-or-string-start ppss)))
(save-excursion
(save-restriction
;; If we're not inside a string, then do very basic
;; filling. This avoids corrupting embedded strings in
;; code.
- (if (not (ppss-comment-or-string-start ppss))
+ (if (not string-start)
(lisp--fill-line-simple)
- ;; If we're in a string, then narrow (roughly) to that
- ;; string before filling. This avoids filling Lisp
- ;; statements that follow the string.
- (when (ppss-string-terminator ppss)
- (goto-char (ppss-comment-or-string-start ppss))
- ;; The string may be unterminated -- in that case, don't
- ;; narrow.
- (when (ignore-errors
- (progn
- (forward-sexp 1)
- t))
- (narrow-to-region (1+ (ppss-comment-or-string-start ppss))
- (1- (point)))))
- ;; Move back to where we were.
- (goto-char start)
- ;; We should fill the first line of a string
- ;; separately (since it's usually a doc string).
- (if (= (line-number-at-pos) 1)
- (narrow-to-region (line-beginning-position)
- (line-beginning-position 2))
- (save-excursion
- (goto-char (point-min))
- (forward-line 1)
- (narrow-to-region (point) (point-max))))
+ (unless lisp-fill-paragraph-as-displayed
+ ;; If we're in a string, then narrow (roughly) to that
+ ;; string before filling. This avoids filling Lisp
+ ;; statements that follow the string.
+ (when (ppss-string-terminator ppss)
+ (goto-char string-start)
+ ;; The string may be unterminated -- in that case, don't
+ ;; narrow.
+ (when (ignore-errors
+ (progn
+ (forward-sexp 1)
+ t))
+ (narrow-to-region (1+ string-start)
+ (1- (point)))))
+ ;; Move back to where we were.
+ (goto-char start)
+ ;; We should fill the first line of a string
+ ;; separately (since it's usually a doc string).
+ (if (= (line-number-at-pos) 1)
+ (narrow-to-region (line-beginning-position)
+ (line-beginning-position 2))
+ (save-excursion
+ (goto-char (point-min))
+ (forward-line 1)
+ (narrow-to-region (point) (point-max)))))
(fill-paragraph justify)))))))
;; Never return nil.
t)
diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el
index da02be65d03..7f5c97ace4d 100644
--- a/test/lisp/emacs-lisp/lisp-mode-tests.el
+++ b/test/lisp/emacs-lisp/lisp-mode-tests.el
@@ -308,6 +308,53 @@ lisp-indent-defun
(indent-region (point-min) (point-max))
(should (equal (buffer-string) orig)))))
+
+;;; Filling
+
+(ert-deftest lisp-fill-paragraph-docstring-boundaries ()
+ "Test bug#28937, ensuring filling the docstring filled is properly
+bounded."
+ (with-temp-buffer
+ (insert "\
+(defun test ()
+ \"This is a test docstring.
+Here is some more text.\"
+ 1
+ 2
+ 3
+ 4
+ 5)")
+ (let ((correct (buffer-string)))
+ (emacs-lisp-mode)
+ (search-backward "This is a test docstring")
+ (fill-paragraph) ;function under test
+ (should (equal (buffer-string) correct)))))
+
+(ert-deftest lisp-fill-paragraph-as-displayed ()
+ "Test bug#56197 -- more specifically, validate that a leading indentation
+for a string is preserved in the filled string."
+ (let ((lisp-fill-paragraph-as-displayed t) ;variable under test
+ ;; The following is a contrived example that demonstrates the
+ ;; fill-column problem when the string to fill is indented.
+ (source "\
+'(description \"This is a very long string which is indented by a considerable value, causing it to
+protrude from the configured `fill-column' since
+lisp-fill-paragraph was refactored in version 28.\")"))
+ (with-temp-buffer
+ (insert source)
+ (emacs-lisp-mode)
+ (search-backward "This is a very long string")
+ (fill-paragraph) ;function under test
+ (goto-char (point-min))
+ (message "%s" (buffer-substring-no-properties (point-min) (point-max)))
+ (let ((i 1)
+ (lines-count (count-lines (point-min) (point-max))))
+ (while (< i lines-count)
+ (beginning-of-line i)
+ (end-of-line)
+ (should (<= (current-column) fill-column))
+ (setq i (1+ i)))))))
+
;;; Fontification
--
2.46.0
Eli Zaretskii wrote 2 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . maxim.cournoyer@gmail.com)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
86r04z6j66.fsf@gnu.org
Toggle quote (14 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: eliz@gnu.org,
> larsi@gnus.org,
> felix.lechner@lease-up.com,
> stefankangas@gmail.com,
> Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date: Sun, 19 Jan 2025 21:51:56 +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 variable allowing opting out of this new behavior in specific
> scenarios (such as when using the Scheme major mode, say).

Thanks, a few minor comments below.

Toggle quote (9 lines)
> * lisp/emacs-lisp/lisp-mode.el (lisp-fill-paragraph-as-displayed): New
> variable.
> (lisp-fill-paragraph): Honor it, by avoiding the logic narrow to strings
> before applying fill-paragraph.
> * test/lisp/emacs-lisp/lisp-mode-tests.el
> (lisp-fill-paragraph-respects-fill-column): Test it.
> (lisp-fill-paragraph-docstring-boundaries): New test, as a safeguard to
> avoid regressions.

Please format these entries according to our conventions, mostly
regarding the line length (it should be at most 69 columns, preferably
no more than 64.

Toggle quote (3 lines)
> -;; Copyright (C) 1985-1986, 1999-2024 Free Software Foundation, Inc.
> +;; Copyright (C) 1985-1986, 1999-2025 Free Software Foundation, Inc.

Please rebase on the current master branch, where the copyright years
were already updated.

Toggle quote (8 lines)
> +(defvar lisp-fill-paragraph-as-displayed nil
> + "This variable can be set to true to fill paragraphs as displayed in the
> +buffer, preserving surrounding context such as the leading indentation.
> +This is useful if respecting `fill-column' is more important than
> +preventing surrounding code from being filled, and makes
> +`lisp-fill-paragraph' behave as it used to in Emacs 27 and prior
> +versions.")

The first line of a doc string should be a single full sentence.
(This is because the various apropos commands show only the first
line.)

More importantly, I think this doc string should describe the main use
case for which the default behavior is tuned: filling Emacs Lisp doc
strings, with their special treatment of the first line.
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87ikq8c2eo.fsf@gmail.com
Hi,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (13 lines)
>> * lisp/emacs-lisp/lisp-mode.el (lisp-fill-paragraph-as-displayed): New
>> variable.
>> (lisp-fill-paragraph): Honor it, by avoiding the logic narrow to strings
>> before applying fill-paragraph.
>> * test/lisp/emacs-lisp/lisp-mode-tests.el
>> (lisp-fill-paragraph-respects-fill-column): Test it.
>> (lisp-fill-paragraph-docstring-boundaries): New test, as a safeguard to
>> avoid regressions.
>
> Please format these entries according to our conventions, mostly
> regarding the line length (it should be at most 69 columns, preferably
> no more than 64.

Done. It's odd that when using magit there's no easy way to have this
this set by default (it defaults to use the text-mode major mode). I've
M-x log-edit-mode in the edit buffer to get the .dir-locals.el
preferences applied.

Toggle quote (6 lines)
>> -;; Copyright (C) 1985-1986, 1999-2024 Free Software Foundation, Inc.
>> +;; Copyright (C) 1985-1986, 1999-2025 Free Software Foundation, Inc.
>
> Please rebase on the current master branch, where the copyright years
> were already updated.

Done.

Toggle quote (16 lines)
>> +(defvar lisp-fill-paragraph-as-displayed nil
>> + "This variable can be set to true to fill paragraphs as displayed in the
>> +buffer, preserving surrounding context such as the leading indentation.
>> +This is useful if respecting `fill-column' is more important than
>> +preventing surrounding code from being filled, and makes
>> +`lisp-fill-paragraph' behave as it used to in Emacs 27 and prior
>> +versions.")
>
> The first line of a doc string should be a single full sentence.
> (This is because the various apropos commands show only the first
> line.)
>
> More importantly, I think this doc string should describe the main use
> case for which the default behavior is tuned: filling Emacs Lisp doc
> strings, with their special treatment of the first line.

I expound the docstring to add more information w.r.t. to the default
behavior of `lisp-fill-paragraph'. I hope it addresses your comment.

I'll send v3 shortly.

--
Thanks,
Maxim
Maxim Cournoyer wrote 2 months ago
[PATCH v3] lisp: Introduce a `lisp-fill-paragraph-as-displayed' variable.
(address . 56197@debbugs.gnu.org)(address . eliz@gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
20250121025207.19966-1-maxim.cournoyer@gmail.com
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 variable allowing
opting out of this new behavior in specific scenarios (such as
when using the Scheme major mode, say).

* lisp/emacs-lisp/lisp-mode.el
(lisp-fill-paragraph-as-displayed): New variable.
(lisp-fill-paragraph): Honor it, by avoiding the logic narrow to
strings before applying fill-paragraph.
* test/lisp/emacs-lisp/lisp-mode-tests.el
(lisp-fill-paragraph-respects-fill-column): Test it.
(lisp-fill-paragraph-docstring-boundaries): New test, as a
safeguard to avoid regressions.

Fixes: bug#56197
---
lisp/emacs-lisp/lisp-mode.el | 75 +++++++++++++++----------
test/lisp/emacs-lisp/lisp-mode-tests.el | 47 ++++++++++++++++
2 files changed, 92 insertions(+), 30 deletions(-)

Toggle diff (159 lines)
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index 2b75a5fd038..9e8292b992a 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -1431,6 +1431,19 @@ emacs-lisp-docstring-fill-column
:group 'lisp
:version "30.1")
+(defvar lisp-fill-paragraph-as-displayed nil
+ "Modify the behavior of `lisp-fill-paragraph'.
+The default behavior of `lisp-fill-paragraph' is tuned for filling Emacs
+Lisp doc strings, with their special treatment for the first line.
+Particularly, strings are filled in a narrowed context to avoid filling
+surrounding code, which means any leading indent is disregarded, which
+can cause the filled string to extend passed the configured
+`fill-column' variable value. If you would rather fill the string in
+its original context and ensure the `fill-column' value is more strictly
+respected, set this variable to true. Doing so makes
+`lisp-fill-paragraph' behave as it used to in Emacs 27 and prior
+versions.")
+
(defun lisp-fill-paragraph (&optional justify)
"Like \\[fill-paragraph], but handle Emacs Lisp comments and docstrings.
If any of the current line is a comment, fill the comment or the
@@ -1480,42 +1493,44 @@ lisp-fill-paragraph
(derived-mode-p 'emacs-lisp-mode))
emacs-lisp-docstring-fill-column
fill-column)))
- (let ((ppss (syntax-ppss))
- (start (point))
- ;; Avoid recursion if we're being called directly with
- ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
- (fill-paragraph-function t))
+ (let* ((ppss (syntax-ppss))
+ (start (point))
+ ;; Avoid recursion if we're being called directly with
+ ;; `M-x lisp-fill-paragraph' in an `emacs-lisp-mode' buffer.
+ (fill-paragraph-function t)
+ (string-start (ppss-comment-or-string-start ppss)))
(save-excursion
(save-restriction
;; If we're not inside a string, then do very basic
;; filling. This avoids corrupting embedded strings in
;; code.
- (if (not (ppss-comment-or-string-start ppss))
+ (if (not string-start)
(lisp--fill-line-simple)
- ;; If we're in a string, then narrow (roughly) to that
- ;; string before filling. This avoids filling Lisp
- ;; statements that follow the string.
- (when (ppss-string-terminator ppss)
- (goto-char (ppss-comment-or-string-start ppss))
- ;; The string may be unterminated -- in that case, don't
- ;; narrow.
- (when (ignore-errors
- (progn
- (forward-sexp 1)
- t))
- (narrow-to-region (1+ (ppss-comment-or-string-start ppss))
- (1- (point)))))
- ;; Move back to where we were.
- (goto-char start)
- ;; We should fill the first line of a string
- ;; separately (since it's usually a doc string).
- (if (= (line-number-at-pos) 1)
- (narrow-to-region (line-beginning-position)
- (line-beginning-position 2))
- (save-excursion
- (goto-char (point-min))
- (forward-line 1)
- (narrow-to-region (point) (point-max))))
+ (unless lisp-fill-paragraph-as-displayed
+ ;; If we're in a string, then narrow (roughly) to that
+ ;; string before filling. This avoids filling Lisp
+ ;; statements that follow the string.
+ (when (ppss-string-terminator ppss)
+ (goto-char string-start)
+ ;; The string may be unterminated -- in that case, don't
+ ;; narrow.
+ (when (ignore-errors
+ (progn
+ (forward-sexp 1)
+ t))
+ (narrow-to-region (1+ string-start)
+ (1- (point)))))
+ ;; Move back to where we were.
+ (goto-char start)
+ ;; We should fill the first line of a string
+ ;; separately (since it's usually a doc string).
+ (if (= (line-number-at-pos) 1)
+ (narrow-to-region (line-beginning-position)
+ (line-beginning-position 2))
+ (save-excursion
+ (goto-char (point-min))
+ (forward-line 1)
+ (narrow-to-region (point) (point-max)))))
(fill-paragraph justify)))))))
;; Never return nil.
t)
diff --git a/test/lisp/emacs-lisp/lisp-mode-tests.el b/test/lisp/emacs-lisp/lisp-mode-tests.el
index 3a765eab625..96e37114276 100644
--- a/test/lisp/emacs-lisp/lisp-mode-tests.el
+++ b/test/lisp/emacs-lisp/lisp-mode-tests.el
@@ -308,6 +308,53 @@ lisp-indent-defun
(indent-region (point-min) (point-max))
(should (equal (buffer-string) orig)))))
+
+;;; Filling
+
+(ert-deftest lisp-fill-paragraph-docstring-boundaries ()
+ "Test bug#28937, ensuring filling the docstring filled is properly
+bounded."
+ (with-temp-buffer
+ (insert "\
+(defun test ()
+ \"This is a test docstring.
+Here is some more text.\"
+ 1
+ 2
+ 3
+ 4
+ 5)")
+ (let ((correct (buffer-string)))
+ (emacs-lisp-mode)
+ (search-backward "This is a test docstring")
+ (fill-paragraph) ;function under test
+ (should (equal (buffer-string) correct)))))
+
+(ert-deftest lisp-fill-paragraph-as-displayed ()
+ "Test bug#56197 -- more specifically, validate that a leading indentation
+for a string is preserved in the filled string."
+ (let ((lisp-fill-paragraph-as-displayed t) ;variable under test
+ ;; The following is a contrived example that demonstrates the
+ ;; fill-column problem when the string to fill is indented.
+ (source "\
+'(description \"This is a very long string which is indented by a considerable value, causing it to
+protrude from the configured `fill-column' since
+lisp-fill-paragraph was refactored in version 28.\")"))
+ (with-temp-buffer
+ (insert source)
+ (emacs-lisp-mode)
+ (search-backward "This is a very long string")
+ (fill-paragraph) ;function under test
+ (goto-char (point-min))
+ (message "%s" (buffer-substring-no-properties (point-min) (point-max)))
+ (let ((i 1)
+ (lines-count (count-lines (point-min) (point-max))))
+ (while (< i lines-count)
+ (beginning-of-line i)
+ (end-of-line)
+ (should (<= (current-column) fill-column))
+ (setq i (1+ i)))))))
+
;;; Fontification
--
2.46.0
Eli Zaretskii wrote 2 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)(address . felix.lechner@lease-up.com)(address . 56197-done@debbugs.gnu.org)
86plkburg7.fsf@gnu.org
Toggle quote (15 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: eliz@gnu.org,
> larsi@gnus.org,
> felix.lechner@lease-up.com,
> stefankangas@gmail.com,
> Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date: Tue, 21 Jan 2025 11:50:44 +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 variable allowing
> opting out of this new behavior in specific scenarios (such as
> when using the Scheme major mode, say).

Thanks, installed on the master branch, and closing the bug.
Closed
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . stefankangas@gmail.com)(address . felix.lechner@lease-up.com)(address . 56197-done@debbugs.gnu.org)
87cyga99ep.fsf@gmail.com
Hello,

Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (17 lines)
>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Cc: eliz@gnu.org,
>> larsi@gnus.org,
>> felix.lechner@lease-up.com,
>> stefankangas@gmail.com,
>> Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Date: Tue, 21 Jan 2025 11:50:44 +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 variable allowing
>> opting out of this new behavior in specific scenarios (such as
>> when using the Scheme major mode, say).
>
> Thanks, installed on the master branch, and closing the bug.

I appreciate your patience and efforts following this through. Thank
you.

--
Maxim
Closed
Felix Lechner wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
87wmei8anp.fsf@lease-up.com
Hi Eli,

On Sat, Jan 25 2025, Eli Zaretskii wrote:

Toggle quote (7 lines)
>> 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 variable allowing
>> opting out of this new behavior in specific scenarios (such as
>> when using the Scheme major mode, say).

Thanks, but the name is terrible. The name fill-paragraph-as-displayed
is the standard behavior. It would be better to invert the logic and
call it fill-strings-instead-of-paragraphs.

Kind regards
Felix
Eli Zaretskii wrote 2 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
868qqyt4xw.fsf@gnu.org
Toggle quote (18 lines)
> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: Maxim Cournoyer <maxim.cournoyer@gmail.com>, 56197@debbugs.gnu.org,
> larsi@gnus.org, stefankangas@gmail.com
> Date: Sat, 25 Jan 2025 20:24:42 -0800
>
> On Sat, Jan 25 2025, Eli Zaretskii wrote:
>
> >> 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 variable allowing
> >> opting out of this new behavior in specific scenarios (such as
> >> when using the Scheme major mode, say).
>
> Thanks, but the name is terrible. The name fill-paragraph-as-displayed
> is the standard behavior. It would be better to invert the logic and
> call it fill-strings-instead-of-paragraphs.

I'm okay with looking for a better name, but
fill-strings-instead-of-paragraphs doesn't sound like a better one
(and "terrible" is an exaggeration, IMO). How about
fill-paragraph-as-doc-string, by default t?
Maxim Cournoyer wrote 2 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . stefankangas@gmail.com)
878qqx7ia5.fsf@gmail.com
Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

Toggle quote (15 lines)
> Hi Eli,
>
> On Sat, Jan 25 2025, Eli Zaretskii wrote:
>
>>> 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 variable allowing
>>> opting out of this new behavior in specific scenarios (such as
>>> when using the Scheme major mode, say).
>
> Thanks, but the name is terrible. The name fill-paragraph-as-displayed
> is the standard behavior. It would be better to invert the logic and
> call it fill-strings-instead-of-paragraphs.

Do you mean 'fill-paragraph-as-displayed' (which reverts to past Emacs
behavior) *should* be the default standard behavior? Because it
currently isn't.

About changing the name, I think the current naming captures the effect
more generally, not mentioning particularities of docstrings, since the
main effect is to avoid narrowing to the string when refilling, not
avoiding the docstring special handling like filling the first sentence
separately, which still holds when fill-paragraph-as-displayed is t
(which I'm also not a big fan but it's a lesser pain point).

--
Thanks,
Maxim
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
874j1l7i61.fsf@gmail.com
Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (1 lines)
>> From: Felix Lechner <felix.lechner@lease-up.com>
[...]

Toggle quote (9 lines)
>> Thanks, but the name is terrible. The name fill-paragraph-as-displayed
>> is the standard behavior. It would be better to invert the logic and
>> call it fill-strings-instead-of-paragraphs.
>
> I'm okay with looking for a better name, but
> fill-strings-instead-of-paragraphs doesn't sound like a better one
> (and "terrible" is an exaggeration, IMO). How about
> fill-paragraph-as-doc-string, by default t?

That's not a bad name, but my code simply avoids narrowing to strings,
it preserves the special handling for doc strings such as filling the
first sentence separately to the second one, so it wouldn't be accurate
in the current version. We could also turn this special handling off
(which would also be welcome in my use case), then your suggested naming
would make sense.

--
Thanks,
Maxim
Eli Zaretskii wrote 2 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
86wmehr532.fsf@gnu.org
Toggle quote (28 lines)
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Cc: Felix Lechner <felix.lechner@lease-up.com>, 56197@debbugs.gnu.org,
> larsi@gnus.org, stefankangas@gmail.com
> Date: Sun, 26 Jan 2025 23:40:06 +0900
>
> Hi Eli,
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Felix Lechner <felix.lechner@lease-up.com>
> [...]
>
> >> Thanks, but the name is terrible. The name fill-paragraph-as-displayed
> >> is the standard behavior. It would be better to invert the logic and
> >> call it fill-strings-instead-of-paragraphs.
> >
> > I'm okay with looking for a better name, but
> > fill-strings-instead-of-paragraphs doesn't sound like a better one
> > (and "terrible" is an exaggeration, IMO). How about
> > fill-paragraph-as-doc-string, by default t?
>
> That's not a bad name, but my code simply avoids narrowing to strings,
> it preserves the special handling for doc strings such as filling the
> first sentence separately to the second one, so it wouldn't be accurate
> in the current version. We could also turn this special handling off
> (which would also be welcome in my use case), then your suggested naming
> would make sense.

Sorry, I don't follow. The behavior introduced in Emacs 28 was to
fill the paragraph as if it were a doc string, treating the first line
specially. Setting the new variable you added disables that. That is
why I said the variable should be t by default; disabling the new
behavior would then mean resetting it to nil.

So what am I missing?
Maxim Cournoyer wrote 2 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
87zfjbrr0n.fsf@gmail.com
Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

Toggle quote (20 lines)
>> > I'm okay with looking for a better name, but
>> > fill-strings-instead-of-paragraphs doesn't sound like a better one
>> > (and "terrible" is an exaggeration, IMO). How about
>> > fill-paragraph-as-doc-string, by default t?
>>
>> That's not a bad name, but my code simply avoids narrowing to strings,
>> it preserves the special handling for doc strings such as filling the
>> first sentence separately to the second one, so it wouldn't be accurate
>> in the current version. We could also turn this special handling off
>> (which would also be welcome in my use case), then your suggested naming
>> would make sense.
>
> Sorry, I don't follow. The behavior introduced in Emacs 28 was to
> fill the paragraph as if it were a doc string, treating the first line
> specially. Setting the new variable you added disables that. That is
> why I said the variable should be t by default; disabling the new
> behavior would then mean resetting it to nil.
>
> So what am I missing?

Apologies for the confusion, I re-verified and indeed the special
handling of the first line/second line is also disabled by the new
'lisp-fill-paragraph-as-displayed' variable I added (when t). That's
one of two things it does, the other one (which was causing the
protruding fill-column behavior) is the narrowing to the string being
filled. This puts the string alone in a temp buffer and fills it there,
which means there's no indentation anymore, which in turns causes the
protruding of fill-column.

I'm talking about this piece of code:

Toggle snippet (12 lines)
(when (ppss-string-terminator ppss)
(goto-char string-start)
;; The string may be unterminated -- in that case, don't
;; narrow.
(when (ignore-errors
(prong
(forward-sexp 1)
t))
(narrow-to-region (1+ string-start)
(1- (point)))))

That's why I chose the name 'as-displayed', meaning preserve surrounding
context and do not narrow to the string.

With that said, I don't feel strongly about it, so if both Felix and you
feel like 'fill-paragraph-as-doc-string' is more accurate/clear, please
proceed :-).

--
Thanks,
Maxim
Felix Lechner wrote 2 months ago
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . larsi@gnus.org)(name . Eli Zaretskii)(address . eliz@gnu.org)(address . 56197@debbugs.gnu.org)(address . stefankangas@gmail.com)
87r04n55qz.fsf@lease-up.com
Hi,

On Tue, Jan 28 2025, Maxim Cournoyer wrote:

Toggle quote (3 lines)
> if both Felix and you feel like 'fill-paragraph-as-doc-string' is more
> accurate/clear

I would call it 'fill-paragraphs-in-doc-string'. Please also note the
plural.

Kind regards
Felix
Eli Zaretskii wrote 1 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
86h65egdyw.fsf@gnu.org
Toggle quote (15 lines)
> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 56197@debbugs.gnu.org, larsi@gnus.org,
> stefankangas@gmail.com
> Date: Tue, 28 Jan 2025 07:15:48 -0800
>
> Hi,
>
> On Tue, Jan 28 2025, Maxim Cournoyer wrote:
>
> > if both Felix and you feel like 'fill-paragraph-as-doc-string' is more
> > accurate/clear
>
> I would call it 'fill-paragraphs-in-doc-string'. Please also note the
> plural.

Thanks, I renamed the variable.
Felix Lechner wrote 1 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
87jza8icuh.fsf@lease-up.com
Hi Eli,

On Sat, Feb 01 2025, Eli Zaretskii wrote:

Toggle quote (2 lines)
> Thanks, I renamed the variable.

There may have been an oversight. Do you prefer the 'as' preposition
over 'in'? [1] It does not sound like standard English to me.

Kind regards,
Felix

Eli Zaretskii wrote 1 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
86seowco3w.fsf@gnu.org
Toggle quote (14 lines)
> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: maxim.cournoyer@gmail.com, 56197@debbugs.gnu.org, larsi@gnus.org,
> stefankangas@gmail.com
> Date: Sun, 02 Feb 2025 07:29:58 -0800
>
> Hi Eli,
>
> On Sat, Feb 01 2025, Eli Zaretskii wrote:
>
> > Thanks, I renamed the variable.
>
> There may have been an oversight. Do you prefer the 'as' preposition
> over 'in'? [1] It does not sound like standard English to me.

This is not about preferences. "As" is correct because we apply the
rules of a doc string. "In" would be correct if we were talking about
filling doc strings and them only, which is not the case here.
Felix Lechner wrote 1 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
87cyg0gidz.fsf@lease-up.com
Hi Eli,

On Sun, Feb 02 2025, Eli Zaretskii wrote:

Toggle quote (3 lines)
> "In" would be correct if we were talking about filling doc strings and
> them only

Then I would use 'fill-strings-like-doc-strings' or, if the prefix must
match, 'fill-paragraphs-in-strings-like-doc-strings'.

Please also note the plural throughout.

Toggle quote (2 lines)
> "As" is correct because we apply the rules of a doc string.

I assume you are referring to the recommendations from the Emacs
manual. [1]

Kind regards
Felix

Eli Zaretskii wrote 1 months ago
(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
86bjvjckj0.fsf@gnu.org
Toggle quote (15 lines)
> From: Felix Lechner <felix.lechner@lease-up.com>
> Cc: maxim.cournoyer@gmail.com, 56197@debbugs.gnu.org, larsi@gnus.org,
> stefankangas@gmail.com
> Date: Sun, 02 Feb 2025 13:13:12 -0800
>
> Hi Eli,
>
> On Sun, Feb 02 2025, Eli Zaretskii wrote:
>
> > "In" would be correct if we were talking about filling doc strings and
> > them only
>
> Then I would use 'fill-strings-like-doc-strings' or, if the prefix must
> match, 'fill-paragraphs-in-strings-like-doc-strings'.

"As" and "like" are synonyms in this case. And using "string" twice
in the name sounds like unnecessary tautology to me. "Paragraphs" is
better, because we do really fill paragraphs, not strings.

So I see nothing wrong with the current name that would justify yet
another rename. We are splitting hair, IMO.

Toggle quote (5 lines)
> > "As" is correct because we apply the rules of a doc string.
>
> I assume you are referring to the recommendations from the Emacs
> manual. [1]

I referred to the basics of the English language.
Maxim Cournoyer wrote 1 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(name . Felix Lechner)(address . felix.lechner@lease-up.com)(address . stefankangas@gmail.com)
8734gvf947.fsf@gmail.com
Hi,

Eli Zaretskii <eliz@gnu.org> writes:

Toggle quote (15 lines)
>> From: Felix Lechner <felix.lechner@lease-up.com>
>> Cc: maxim.cournoyer@gmail.com, 56197@debbugs.gnu.org, larsi@gnus.org,
>> stefankangas@gmail.com
>> Date: Sun, 02 Feb 2025 13:13:12 -0800
>>
>> Hi Eli,
>>
>> On Sun, Feb 02 2025, Eli Zaretskii wrote:
>>
>> > "In" would be correct if we were talking about filling doc strings and
>> > them only
>>
>> Then I would use 'fill-strings-like-doc-strings' or, if the prefix must
>> match, 'fill-paragraphs-in-strings-like-doc-strings'.

Felix, what is the reason you insist on the 'in-strings' part? Is this
to try to express the fact that the code is narrowing down on
strings and *then* filling, rather than filling everything at and around
the pointer?

Toggle quote (7 lines)
> "As" and "like" are synonyms in this case. And using "string" twice
> in the name sounds like unnecessary tautology to me. "Paragraphs" is
> better, because we do really fill paragraphs, not strings.
>
> So I see nothing wrong with the current name that would justify yet
> another rename. We are splitting hair, IMO.

It seems to me there is diminishing returns at this point trying to nail
the elusive perfect name :-). I'd suggest we move on.

--
Thanks,
Maxim
Felix Lechner wrote 1 months ago
(name . Eli Zaretskii)(address . eliz@gnu.org)(address . larsi@gnus.org)(address . 56197@debbugs.gnu.org)(address . maxim.cournoyer@gmail.com)(address . stefankangas@gmail.com)
87seovf3gt.fsf@lease-up.com
Hi Eli,

On Mon, Feb 03 2025, Eli Zaretskii wrote:

Toggle quote (2 lines)
> "As" and "like" are synonyms in this case.

They are not the same. One is a preposition, and the other is a
conjunction. [1][2]


Toggle quote (2 lines)
> And using "string" twice in the name sounds like unnecessary tautology

A tautotology means something that's always true. It's a term from
formal logic. Did you mean a pleonasm instead? [3] People often use
both words interchangably, but a pleonasm is the right way to describe
logically redundant language.

My suggestion isn't redundant because docstrings are more specific than
strings. For example, there is no redundancy in the statement "the boat
looked like a sailboat." Therefore it is also not redundant to "format
a string like a docstring".

The logical principle of the general vs. the specific has been around
for 1,800 years: The Beraita of Rabbi Yishmael says in verse 4 (with my
elaboration): "When a general rule is followed by an explicit
particular, the rule is limited to the explicit particular." [4][5]


Toggle quote (3 lines)
> "Paragraphs" is better, because we do really fill paragraphs, not
> strings.

Are we? I think we are formatting strings.

Toggle quote (2 lines)
> We are splitting hair, IMO.

A love of language helps people communicate. For example, I talk to my
neighbor in English, and not in Python (even though I think he is a
programmer). I think you chose 'as' simply because it is shorter.

Of course, you are entitled to your choices.

Also, aren't you and I picky the same way? As Maxim noted, you disagree
with my preference for "in" but unlike me, you signalled agreement where
there was none. You wrote that you changed the name but withheld the
details. I had to go look.

Ultimately, you can do whatever you like. I am truly grateful for
Emacs. Thank you for maintaining it!

Kind regards
Felix
?
Your comment

This issue is archived.

To comment on this conversation send an email to 56197@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56197
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help