GNU bug report logs -
#56197
lisp-fill-paragraph behavior changed in Emacs 28
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56197 in the body.
You can then email your comments to 56197 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Fri, 24 Jun 2022 16:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 24 Jun 2022 16:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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/lisp/org/ol-mhe
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-man hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-man
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-irc hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-irc
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-info hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-info
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-gnus hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-gnus
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-eww hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-eww
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-eshell hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-eshell
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-doi hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-doi
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ol-docview hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ol-docview
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/oc-natbib hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/oc-natbib
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/oc-biblatex hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/oc-biblatex
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-table hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-table
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-sqlite hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-sqlite
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-screen hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-screen
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-sed hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-sed
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-scheme hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-scheme
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-sass hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-sass
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-ref hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-ref
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-processing hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-processing
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-plantuml hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-plantuml
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-perl hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-perl
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-org hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-org
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-ocaml hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-ocaml
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-maxima hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-maxima
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-matlab hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-matlab
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-makefile hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-makefile
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-lob hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-lob
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-lisp hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-lisp
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-latex hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-latex
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-js hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-js
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-groovy hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-groovy
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-fortran hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-fortran
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-forth hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-forth
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-eval hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-eval
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-eshell hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-eshell
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-dot hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-dot
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-emacs-lisp hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-emacs-lisp
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-ditaa hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-ditaa
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-css hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-css
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-clojure hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-clojure
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-calc hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-calc
/gnu/store/fw7xksf83zqxpsvpxmq1li3sc1qiwfsq-emacs-org-9.5.3/share/emacs/site-lisp/org-9.5.3/ob-awk hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/org/ob-awk
/gnu/store/rpih6axr0g2sv1yz2q7gjby4df82wb47-emacs-soap-client-3.2.1/share/emacs/site-lisp/soap-client-3.2.1/soap-inspect hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/net/soap-inspect
/gnu/store/rpih6axr0g2sv1yz2q7gjby4df82wb47-emacs-soap-client-3.2.1/share/emacs/site-lisp/soap-client-3.2.1/soap-client hides /gnu/store/q6x17s6zcgv52sdz3gh69b7g0d9712z8-emacs-28.1/share/emacs/28.1/lisp/net/soap-client
Features:
(shadow emacsbug whitespace elp edebug backtrace apropos gnus-kill
perl-mode tramp-archive tramp-gvfs rst robot-mode align rect json-mode
json-snatcher pulse nroff-mode markdown-mode php-mode mode-local
cc-langs php-face php php-project projectile lisp-mnt ibuf-ext ibuffer
ibuffer-loaddefs find-dired rng-cmpct rng-nxml rng-valid nxml-mode
nxml-outln nxml-rap cus-start cl-print shortdoc nix-mode nix-repl
nix-shell nix-store nix-instantiate nix-shebang nix-format nix log-view
vc-annotate woman man novice font-latex plain-tex tex-buf latex
latex-flymake tex-ispell tex-style tex-mode latexenc logview datetime
extmap conf-mode time-stamp dabbrev sh-script executable ggtags
mhtml-mode css-mode smie js cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs sgml-mode facemenu
tramp-cache tramp-adb arc-mode archive-mode magit-patch magit-subtree
magit-ediff ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util guix-build-log guix-scheme tex-info tex texmathp
texinfo texinfo-loaddefs nndoc gnus-dup url-cache git-rebase
bash-completion magit-gitignore autoconf autoconf-mode cal-move
make-mode vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
goto-addr bug-reference vc-git magit-extras copyright face-remap
magit-bookmark magit-submodule magit-obsolete magit-popup magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
git-commit log-edit pcvs-util magit-core magit-autorevert autorevert
filenotify magit-margin magit-transient magit-process with-editor
magit-mode magit-git magit-section magit-utils dired-aux gnus-dired
misearch multi-isearch flow-fill guix-devel edit-indirect guix-misc
guix-ui guix-ui-messages bui bui-list bui-info bui-entry bui-core
bui-history bui-button guix-read guix-help-vars guix-repl guix-profiles
guix-external guix-config guix-build-config guix-geiser geiser-mode
geiser-xref guix-guile geiser-guile info-look info geiser geiser-repl
geiser-compile geiser-debug transient geiser-image geiser-company
geiser-doc geiser-menu geiser-edit geiser-completion geiser-autodoc
geiser-eval geiser-connection geiser-syntax geiser-impl geiser-log
geiser-popup view geiser-custom geiser-base guix-utils guix bui-utils
dash scheme ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
ol-docview ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi mule-util
smtpmail mailalias sendmail bbdb-com crm bbdb bbdb-site smiley gnus-cite
mm-archive mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table nndraft
nnmh utf-7 epa-file gnutls network-stream nnnil gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view
mml-smime smime dig nntp gnus-cache gnus-sum shr kinsoku svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rfc822
mml mml-sec mailabbrev gmm-utils mailheader gnus-win gnus nnheader
gnus-util rmail rmail-loaddefs mail-utils bookmark server paredit
diff-hl vc-dir ewoc vc vc-dispatcher flyspell ispell company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-files company-cmake company-xcode company-clang
company-semantic company-eclim company-template company-bbdb htmlize
ox-reveal ox-odt rng-loc rng-uri rng-parse rng-match rng-pttrn
nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar
org-agenda org-refile ox-html table ox-ascii ox-publish ox org-element
avl-tree dired-x w3m doc-view jka-compr image-mode exif timezone
w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-favicon w3m-image tab-line
w3m-proc w3m-util highlight-indentation flymake-proc flymake
company-capf help-fns radix-tree elpy elpy-rpc pyvenv eshell esh-cmd
esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
elpy-shell elpy-profile elpy-django s elpy-refactor diff-mode python
tramp-sh tramp tramp-loaddefs trampver tramp-integration tramp-compat
shell parse-time ls-lisp ido hideshow files-x etags fileloop generator
cus-edit pp yasnippet-snippets yasnippet ffap debbugs-gnu add-log
debbugs-compat debbugs soap-client mm-decode mm-bodies mm-encode
url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny warnings rng-xsd rng-dt rng-util
xsd-regexp emms-librefm-stream xml emms-librefm-scrobbler
emms-playlist-limit emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-browser sort emms-volume emms-volume-sndioctl emms-volume-mixerctl
emms-volume-pulse emms-volume-amixer emms-playlist-sort emms-last-played
emms-player-xine emms-player-mpd tq emms-lyrics emms-url emms-streams
emms-show-all emms-tag-editor emms-tag-tracktag emms-mode-line
emms-cache emms-info-native bindat emms-info-exiftool emms-info-tinytag
emms-info-opusinfo emms-info-ogginfo emms-info-mp3info emms-player-vlc
emms-player-mpv emms-playing-time emms-player-mplayer emms-player-simple
emms-playlist-mode emms-source-playlist emms-source-file thingatpt
locate emms-mark emms-setup emms-info-metaflac emms-info emms-later-do
emms emms-compat cal-china lunar solar cal-dst cal-bahai cal-islam
cal-hebrew holidays hol-loaddefs appt diary-lib diary-loaddefs
string-inflection org-clock org-tempo org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
pcomplete org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex iso8601
time-date ol org-keys oc org-compat org-macs org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs tempo ws-butler epa derived epg
rfc6068 epg-config grep-a-lot grep counsel xdg advice xref project dired
dired-loaddefs compile text-property-search comint ansi-color swiper
cl-extra help-mode ivy delsel ivy-faces ivy-overlay colir color
easy-mmode robot-log-autoloads robot-log so-long recentf tree-widget
wid-edit company edmacro kmacro pcase elec-pair savehist winner ring
time cus-load feature-mode-autoloads clang-rename-autoloads
clang-format-autoloads markup-faces-autoloads adoc-mode-autoloads
yasnippet-snippets-autoloads yaml-mode-autoloads ws-butler-autoloads
w3m-load string-inflection-autoloads sr-speedbar-autoloads
rust-mode-autoloads rpm-spec-mode-autoloads robot-mode-autoloads
loc-changes-autoloads load-relative-autoloads realgud-autoloads
realgud-recursive-autoloads qml-mode-autoloads tablist-autoloads
pdf-tools-autoloads epl-autoloads pkg-info-autoloads
projectile-autoloads php-mode-autoloads paredit-autoloads
org-reveal-autoloads org-autoloads mmm-mode-autoloads
json-snatcher-autoloads json-mode-autoloads nix-mode-autoloads
markdown-mode-autoloads async-autoloads with-editor-autoloads
magit-autoloads extmap-autoloads datetime-autoloads logview-autoloads
jenkinsfile-mode-autoloads htmlize-autoloads magit-popup-autoloads
geiser-guile-autoloads transient-autoloads xref-autoloads
project-autoloads geiser-autoloads edit-indirect-autoloads bui-autoloads
guix-autoloads rx dash-autoloads groovy-modes-autoloads
grep-a-lot-autoloads go-mode-autoloads xpm-autoloads
ascii-art-to-unicode-autoloads gnugo-autoloads ggtags-autoloads
emms-autoloads s-autoloads pyvenv-autoloads yasnippet-autoloads
highlight-indentation-autoloads find-file-in-project-autoloads
elpy-autoloads el-mock-autoloads diff-hl-autoloads soap-client-autoloads
debbugs-autoloads csv-mode-autoloads counsel-bbdb-autoloads
hydra-autoloads ivy-autoloads swiper-autoloads counsel-autoloads
pos-tip-autoloads company-quickhelp-autoloads company-autoloads
cmake-mode-autoloads bbdb-autoloads bash-completion-autoloads
auctex-autoloads tex-site guix-emacs package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 5047295 585780)
(symbols 48 76444 4)
(strings 32 532649 231222)
(string-bytes 1 19695544)
(vectors 16 216067)
(vector-slots 8 3662568 496790)
(floats 8 6626 1776)
(intervals 56 446059 14706)
(buffers 992 580))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jun 2022 11:54:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer <maxim.cournoyer <at> 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?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jun 2022 12:44:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> Cc: 56197 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 25 Jun 2022 13:53:44 +0200
>
> Maxim Cournoyer <maxim.cournoyer <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jun 2022 12:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> 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.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jun 2022 12:50:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 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.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jun 2022 13:01:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> `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.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Mon, 27 Jun 2022 01:54:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hello,
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Maxim Cournoyer <maxim.cournoyer <at> 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:
--8<---------------cut here---------------start------------->8---
(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 <at> tie{}3. This package contains both
the non-variable as well as the variable versions of the font.")
(license license:silofl1.1)))
--8<---------------cut here---------------end--------------->8---
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Wed, 29 Jun 2022 18:04:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 30 Jun 2022 09:33:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> 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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 30 Jun 2022 09:34:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) pending.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 30 Jun 2022 09:34:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 30 Jun 2022 12:29:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 56197 <at> debbugs.gnu.org (full text, mbox):
On June 30, 2022 5:32:08 AM EDT, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>Stefan Kangas <stefan <at> 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,
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Fri, 01 Jul 2022 09:06:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> 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.
> 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.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Wed, 25 Dec 2024 20:16:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi everyone,
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 26 Dec 2024 06:22:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Felix Lechner <felix.lechner <at> lease-up.com>
> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Stefan Kangas
> <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen
> <larsi <at> gnus.org>
> Date: Wed, 25 Dec 2024 12:15:44 -0800
>
> > fill the string using fill-column, or [...] fill the text as is in the
> > buffer
>
> > It's now filling that string as if it, well, is a string, so that if
> > you insert it somewhere, the lines have similar lengths. The previous
> > behaviour was to fill "what you see in the buffer"
>
> > The former sounds more useful, IMO. I don't want to mess up my strings
> > just to have pretty source code
>
> Filling strings in code would be useful, but isn't that a separate,
> don't-break-my-strings feature?
Not necessarily. I frequently fill stuff in my code, and don't want
to use a separate command if the region I fill includes strings (or
comments, or something other that needs special filling behavior).
> Historically, the point of text justification is to make text fit on a
> screen. For example, the documentation for fill-region refers to
> columns, which are features of buffers:
>
> Column beyond which automatic line-wrapping should happen.
>
> Auto-fill-mode is consistent:
>
> inserting a space at a column beyond current-fill-column
> automatically breaks the line
>
> In a grand sweep, the manual explains what needs to fit where:
>
> “Filling” text means breaking it up into lines that fit a specified
> width.
>
> Section 26.6.2 ("Explicit Fill Commands") is even more, well, explicit:
>
> The command ‘M-q’ (‘fill-paragraph’) “fills” the current paragraph.
> It redistributes the line breaks within the paragraph, and deletes
> any excess space and tab characters occurring within the paragraph,
> in such a way that the lines end up fitting within a certain maximum
> width.
>
> How text shows on a screen is clearly a central feature. The manual
> continues:
>
> The maximum line width for filling is specified by the buffer-local
> variable ‘fill-column’. The default value (*note Locals::) is 70.
> The easiest way to set ‘fill-column’ in the current buffer is to use
> the command ‘C-x f’ (‘set-fill-column’). [...] Note that, by its
> very nature, ‘fill-column’ is measured in column units; the actual
> position of that column on a graphical display depends on the font
> being used. In particular, using variable-pitch fonts will cause
> the ‘fill-column’ occupy different horizontal positions on display
> in different lines.
>
> In my view, the string interpretation calls for a different, though
> related feature.
You are quoting text which talks about the _default_ filling. The
default filling is tailored to "uniform" text, i.e. really to Text
mode and its descendants.
However, Emacs lets major modes customize filling as appropriate for
the mode, by defining mode-specific filling functions. Which is what
happens in this case: lisp-mode.el defines a fill-paragraph function
that is specific to Lisp modes. It is completely legitimate for such
mode-specific functions to special-case strings inside code and do
something special about that.
So I don't see how what we do now is against the spirit of filling.
(Btw, I think it's high time we closed that bug, since Emacs 28.2 was
released long ago.)
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility.
(Thu, 26 Dec 2024 15:18:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
bug acknowledged by developer.
(Thu, 26 Dec 2024 15:18:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 56197-done <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 05:28:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> Filling strings in code would be useful, but isn't that a separate,
>> don't-break-my-strings feature?
>
> Not necessarily. I frequently fill stuff in my code, and don't want
> to use a separate command if the region I fill includes strings (or
> comments, or something other that needs special filling behavior).
I agree that having a single way to 'fill text/code/whatever' is nice.
[...]
> You are quoting text which talks about the _default_ filling. The
> default filling is tailored to "uniform" text, i.e. really to Text
> mode and its descendants.
>
> However, Emacs lets major modes customize filling as appropriate for
> the mode, by defining mode-specific filling functions. Which is what
> happens in this case: lisp-mode.el defines a fill-paragraph function
> that is specific to Lisp modes. It is completely legitimate for such
> mode-specific functions to special-case strings inside code and do
> something special about that.
>
> So I don't see how what we do now is against the spirit of filling.
Maybe it doesn't in general, but in the case of Guix packages, it's
strikingly odd compared to the past behavior which was respecting the
fill-column in a long multi-line string (refer to the original issue I
had detailed in this thread for an example).
> (Btw, I think it's high time we closed that bug, since Emacs 28.2 was
> released long ago.)
It's a change of behavior introduced in version 28 that apparently
doesn't make unanimity (though perhaps noticed mostly by Guix
developers, where the use of the multi-line strings for package
descriptions makes this issue very visible and annoying); the GNU Guix
project has been carrying this in its .dir-locals.el file, which simply
reverts to the old behavior before commit 9bf367e1848:
--8<---------------cut here---------------start------------->8---
;; Emacs 28 changed the behavior of 'lisp-fill-paragraph', which causes the
;; first line of package descriptions to extrude past 'fill-column', and
;; somehow that is deemed more correct upstream (see:
;; https://issues.guix.gnu.org/56197).
(eval . (progn
(require 'lisp-mode)
(defun emacs27-lisp-fill-paragraph (&optional justify)
(interactive "P")
(or (fill-comment-paragraph justify)
(let ((paragraph-start
(concat paragraph-start
"\\|\\s-*\\([(;\"]\\|\\s-:\\|`(\\|#'(\\)"))
(paragraph-separate
(concat paragraph-separate "\\|\\s-*\".*[,\\.]$"))
(fill-column (if (and (integerp emacs-lisp-docstring-fill-column)
(derived-mode-p 'emacs-lisp-mode))
emacs-lisp-docstring-fill-column
fill-column)))
(fill-paragraph justify))
;; Never return nil.
t))
(setq-local fill-paragraph-function #'emacs27-lisp-fill-paragraph)))
--8<---------------cut here---------------end--------------->8---
I can't say it feels very satisfactory; a switch like one imagined by
Felix could be a step in the right direction; it'd be at least more
concise in the project .dir-locals. Would a patch implementing that be
welcome?
Happy New Year,
--
Maxim
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 05:55:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 56197-done <at> debbugs.gnu.org (full text, mbox):
Hi Stefan,
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 08:46:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: Felix Lechner <felix.lechner <at> lease-up.com>, 56197 <at> debbugs.gnu.org,
> stefankangas <at> gmail.com, larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 08:48:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>,
> 56197-done <at> debbugs.gnu.org
> Date: Sat, 28 Dec 2024 14:52:52 +0900
>
> Hi Stefan,
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
> > Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> >
> >> Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 08:54:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 56197 <at> debbugs.gnu.org (full text, mbox):
reopen 56197
thanks
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hi Stefan,
>
> Stefan Kangas <stefankangas <at> 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.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 28 Dec 2024 08:54:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 14:53:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
Eli Zaretskii <eliz <at> gnu.org> 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.
>
> 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
Changed bug title to 'lisp-fill-paragraph behavior changed in Emacs 28' from '28.1; lisp-fill-paragraph result regressed with Emacs 28'
Request was from
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 28 Dec 2024 14:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 28 Dec 2024 15:17:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Cc: Felix Lechner <felix.lechner <at> lease-up.com>, 56197 <at> debbugs.gnu.org,
>> stefankangas <at> gmail.com, larsi <at> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 10:10:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 56197 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Eli et al.,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
[...]
>> 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.
[0001-test-lisp-Add-new-test-for-filling-behavior-change.patch (text/x-patch, attachment)]
[0002-test-lisp-Add-a-test-checking-docstring-boundaries-w.patch (text/x-patch, attachment)]
[0003-wip-work-on-solution.patch (text/x-patch, attachment)]
[Message part 5 (text/plain, inline)]
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.
[0] https://paredit.org/cgit/paredit/tree/paredit.el#n1066
--
Thanks,
Maxim
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 10:15:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi again,
[...]
> 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:
--8<---------------cut here---------------start------------->8---
(setq-local fill-paragraph-function 'lisp-fill-paragraph)
--8<---------------cut here---------------end--------------->8---
--
Thanks,
Maxim
Information forwarded
to
eliz <at> gnu.org, larsi <at> gnus.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com, bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 13:05:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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(-)
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 <at> 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
Added tag(s) patch.
Request was from
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 04 Jan 2025 13:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, eliz <at> gnu.org, larsi <at> gnus.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Sat, 4 Jan 2025 22:03:43 +0900
>
> Starting with Emacs 28, filling strings now happens in a narrowed scope,
> and looses the leading indentation and can cause the string to extend
> past the fill-column value. Introduce lisp-fill-paragraph-as-displayed
> as a new option allowing users to easily opt out of this new behavior.
Thanks. But this is not a user-level problem, so the variable to
control this should IMO be a defvar, not a defcustom. Then Lisp
programs which need to get back old behavior for some reason could
bind the variable around the call.
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 14:05:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com,
> stefankangas <at> gmail.com
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 04 Jan 2025 14:20:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com,
> stefankangas <at> gmail.com
> Date: Sat, 04 Jan 2025 16:04:36 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> > Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com,
> > stefankangas <at> gmail.com
> > 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".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Tue, 14 Jan 2025 04:52:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 16 Jan 2025 05:06:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, eliz <at> gnu.org,
>> larsi <at> gnus.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Sat, 4 Jan 2025 22:03:43 +0900
>>
>> Starting with Emacs 28, filling strings now happens in a narrowed scope,
>> and looses the leading indentation and can cause the string to extend
>> past the fill-column value. Introduce lisp-fill-paragraph-as-displayed
>> as a new option allowing users to easily opt out of this new behavior.
>
> Thanks. But this is not a user-level problem, so the variable to
> control this should IMO be a defvar, not a defcustom. Then Lisp
> programs which need to get back old behavior for some reason could
> bind the variable around the call.
I'm not sure. A user (such as myself) may prefer the old behavior, and
customize lisp-fill-paragraph-as-displayed (setting it to t) so that
this behavior is now the default everywhere. It also makes it
more easily discoverable. So unless you see a strong reason against
using defcustom, it seems preferable to me than defvar.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Thu, 16 Jan 2025 08:23:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: larsi <at> gnus.org, felix.lechner <at> lease-up.com, 56197 <at> debbugs.gnu.org,
> stefankangas <at> gmail.com
> Date: Thu, 16 Jan 2025 14:04:55 +0900
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, eliz <at> gnu.org,
> >> larsi <at> gnus.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
> >> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> >> Date: Sat, 4 Jan 2025 22:03:43 +0900
> >>
> >> Starting with Emacs 28, filling strings now happens in a narrowed scope,
> >> and looses the leading indentation and can cause the string to extend
> >> past the fill-column value. Introduce lisp-fill-paragraph-as-displayed
> >> as a new option allowing users to easily opt out of this new behavior.
> >
> > Thanks. But this is not a user-level problem, so the variable to
> > control this should IMO be a defvar, not a defcustom. Then Lisp
> > programs which need to get back old behavior for some reason could
> > bind the variable around the call.
>
> I'm not sure. A user (such as myself) may prefer the old behavior, and
> customize lisp-fill-paragraph-as-displayed (setting it to t) so that
> this behavior is now the default everywhere. It also makes it
> more easily discoverable. So unless you see a strong reason against
> using defcustom, it seems preferable to me than defvar.
Users can also set a defvar, if they want this globally. However, the
original problem is not a global one, it is specific to some
situations in some particular major mode.
The important question here is: how common is the situation where a
user will prefer to set that globally? I think this could only happen
if the user uses a major mode of just one variant of Lisp-like
languages, and especially if that one variant is not Emacs Lisp.
In addition, making it a defcustom means Lisp programs cannot easily
bind it to specific values when they need it (overriding user options
is considered unclean in Emacs).
So my preference is to introduce a defvar, and only promote it to a
user option if we have enough demand in the future.
> > P.S. I don't see your copyright assignment on file, so if you want to
> > contribute such large changes, let's please start your legal paperwork
> > of assigning the copyright to the FSF. OK?
>
> That's fine; I'm happy to assign my copyright w.r.t. Emacs changes to
> the FSF; please send the paperwork over!
Will do, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 19 Jan 2025 12:37:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hello Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> > 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 19 Jan 2025 12:54:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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(-)
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 19 Jan 2025 13:14:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: eliz <at> gnu.org,
> larsi <at> gnus.org,
> felix.lechner <at> lease-up.com,
> stefankangas <at> gmail.com,
> Maxim Cournoyer <maxim.cournoyer <at> 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.
> * 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.
> -;; 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.
> +(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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Tue, 21 Jan 2025 02:44:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi,
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> * 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.
>> -;; 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.
>> +(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Tue, 21 Jan 2025 02:53:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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(-)
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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 25 Jan 2025 10:20:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
bug acknowledged by developer.
(Sat, 25 Jan 2025 10:20:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 56197-done <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: eliz <at> gnu.org,
> larsi <at> gnus.org,
> felix.lechner <at> lease-up.com,
> stefankangas <at> gmail.com,
> Maxim Cournoyer <maxim.cournoyer <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 25 Jan 2025 15:55:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 56197-done <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Cc: eliz <at> gnu.org,
>> larsi <at> gnus.org,
>> felix.lechner <at> lease-up.com,
>> stefankangas <at> gmail.com,
>> Maxim Cournoyer <maxim.cournoyer <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 26 Jan 2025 04:25:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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.
Kind regards
Felix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 26 Jan 2025 07:23:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Felix Lechner <felix.lechner <at> lease-up.com>
> Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 56197 <at> debbugs.gnu.org,
> larsi <at> gnus.org, stefankangas <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 26 Jan 2025 14:38:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Felix,
Felix Lechner <felix.lechner <at> lease-up.com> writes:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 26 Jan 2025 14:41:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Felix Lechner <felix.lechner <at> 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.
--
Thanks,
Maxim
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 26 Jan 2025 15:03:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Cc: Felix Lechner <felix.lechner <at> lease-up.com>, 56197 <at> debbugs.gnu.org,
> larsi <at> gnus.org, stefankangas <at> gmail.com
> Date: Sun, 26 Jan 2025 23:40:06 +0900
>
> Hi Eli,
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Felix Lechner <felix.lechner <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Tue, 28 Jan 2025 13:46:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
>> > 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:
--8<---------------cut here---------------start------------->8---
(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)))))
--8<---------------cut here---------------end--------------->8---
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Tue, 28 Jan 2025 15:16:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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.
Kind regards
Felix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sat, 01 Feb 2025 10:25:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Felix Lechner <felix.lechner <at> lease-up.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 56197 <at> debbugs.gnu.org, larsi <at> gnus.org,
> stefankangas <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 02 Feb 2025 15:31:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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.
Kind regards,
Felix
[1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e067f2763fd52b78342b5c759205032227e82ebe
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 02 Feb 2025 16:24:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Felix Lechner <felix.lechner <at> lease-up.com>
> Cc: maxim.cournoyer <at> gmail.com, 56197 <at> debbugs.gnu.org, larsi <at> gnus.org,
> stefankangas <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Sun, 02 Feb 2025 21:14:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 56197 <at> debbugs.gnu.org (full text, mbox):
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'.
Please also note the plural throughout.
> "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
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Documentation-Tips.html#Documentation-Tips
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Mon, 03 Feb 2025 11:54:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 56197 <at> debbugs.gnu.org (full text, mbox):
> From: Felix Lechner <felix.lechner <at> lease-up.com>
> Cc: maxim.cournoyer <at> gmail.com, 56197 <at> debbugs.gnu.org, larsi <at> gnus.org,
> stefankangas <at> 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.
> > "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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Mon, 03 Feb 2025 13:32:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi,
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Felix Lechner <felix.lechner <at> lease-up.com>
>> Cc: maxim.cournoyer <at> gmail.com, 56197 <at> debbugs.gnu.org, larsi <at> gnus.org,
>> stefankangas <at> 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?
> "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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#56197; Package
emacs.
(Mon, 03 Feb 2025 15:34:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 56197 <at> debbugs.gnu.org (full text, mbox):
Hi Eli,
On Mon, Feb 03 2025, Eli Zaretskii wrote:
> "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]
[1] https://dictionary.cambridge.org/grammar/british-grammar/as-or-like
[2] https://www.grammarly.com/blog/commonly-confused-words/like-vs-as/
> 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]
[3] https://en.wikipedia.org/wiki/Pleonasm
[4] https://www.sefaria.org/Sifra%2C_Baraita_DeRabbi_Yishmael?lang=bi
[5] https://outorah.org/p/6480
> "Paragraphs" is better, because we do really fill paragraphs, not
> strings.
Are we? I think we are formatting strings.
> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 04 Mar 2025 12:24:19 GMT)
Full text and
rfc822 format available.
This bug report was last modified 65 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.