* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
@ 2023-11-26 21:08 Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 21:23 ` Dmitry Gutov
0 siblings, 1 reply; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-26 21:08 UTC (permalink / raw)
To: 67462
[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]
There seems to be a regression introduced with function
`prog-fill-reindent-defun' from commit b889eced4449. To see the
difference in behavior, start
emacs -Q test.mk
with attached test.mk and try filling (with M-q) the paragraphs starting
with "FOO = ..." and "foo: ..." both in Emacs 29 and in Emacs 30. With
Emacs 29, I get as result:
------------------------- test.mk -------------------------
FOO = barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
barbarbarbar barbarbarbar barbarbarbar barbarbarbar \
barbarbarbar; foobarbaz
foo: ; barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
barbarbarbar barbarbarbar barbarbarbar barbarbarbar \
barbarbarbar; foobarbaz
------------------------- test.mk -------------------------
In Emacs 30, M-q does not have any effect on the paragraphs.
My analysis:
- In Emacs 29, M-q is bound to `fill-paragraph' in makefile-mode buffers
through global bindings. That function respects the makefile-mode
specific setting of `fill-paragraph-function':
;; Filling.
(setq-local fill-paragraph-function 'makefile-fill-paragraph)
- In Emacs 30, M-q is bound to `prog-fill-reindent-defun' in
makefile-mode buffers through `prog-mode-map'. That function does not
care about any buffer-local values of `fill-paragraph-function'
outside of comments and strings.
Personally, I find the filling done by `makefile-fill-paragraph'
questionable, and I really don't use it. But others probably care more,
in particular for modes having implementations of
`fill-paragraph-function' that actually do something useful on code ...
A possible fix might look like this:
diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
index 37c54a90f42..1bb2b678d94 100644
--- a/lisp/progmodes/prog-mode.el
+++ b/lisp/progmodes/prog-mode.el
@@ -163,7 +163,8 @@ prog-fill-reindent-defun
(treesit-parser-list)
(treesit-node-match-p
(treesit-node-at (point)) 'text t))))
- (if (or treesit-text-node
+ (if (or (local-variable-p 'fill-paragraph-function)
+ treesit-text-node
(nth 8 (syntax-ppss))
(re-search-forward "\\s-*\\s<" (line-end-position) t))
(fill-paragraph argument (region-active-p))
I can provide a patch along those lines, but a "wontfix" is also fine
with me.
[-- Attachment #2: test.mk --]
[-- Type: application/octet-stream, Size: 284 bytes --]
FOO = barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
barbarbarbar barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
foobarbaz
foo: ; barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
barbarbarbar barbarbarbar barbarbarbar barbarbarbar barbarbarbar; \
foobarbaz
[-- Attachment #3: Type: text/plain, Size: 16427 bytes --]
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.24, cairo version 1.16.0) of 2023-11-26 built on sappc2
Repository revision: ea4c5fcd77257d7a7c050714b809b1507d93a6ef
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure -C --with-native-compilation --with-mailutils'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LC_COLLATE: POSIX
value of $LC_TIME: POSIX
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
display-time-mode: t
delete-selection-mode: t
show-paren-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/jschmidt/.emacs.d/elpa/transient-20231123.2131/transient hides /home/jschmidt/work/emacs-master/lisp/transient
/home/jschmidt/work/org-mode/lisp/org-attach hides /home/jschmidt/work/emacs-master/lisp/org/org-attach
/home/jschmidt/work/org-mode/lisp/ob-scheme hides /home/jschmidt/work/emacs-master/lisp/org/ob-scheme
/home/jschmidt/work/org-mode/lisp/ob-processing hides /home/jschmidt/work/emacs-master/lisp/org/ob-processing
/home/jschmidt/work/org-mode/lisp/ob-gnuplot hides /home/jschmidt/work/emacs-master/lisp/org/ob-gnuplot
/home/jschmidt/work/org-mode/lisp/org-element hides /home/jschmidt/work/emacs-master/lisp/org/org-element
/home/jschmidt/work/org-mode/lisp/ob-org hides /home/jschmidt/work/emacs-master/lisp/org/ob-org
/home/jschmidt/work/org-mode/lisp/ob-sql hides /home/jschmidt/work/emacs-master/lisp/org/ob-sql
/home/jschmidt/work/org-mode/lisp/oc-bibtex hides /home/jschmidt/work/emacs-master/lisp/org/oc-bibtex
/home/jschmidt/work/org-mode/lisp/ox-koma-letter hides /home/jschmidt/work/emacs-master/lisp/org/ox-koma-letter
/home/jschmidt/work/org-mode/lisp/ox-icalendar hides /home/jschmidt/work/emacs-master/lisp/org/ox-icalendar
/home/jschmidt/work/org-mode/lisp/ol-gnus hides /home/jschmidt/work/emacs-master/lisp/org/ol-gnus
/home/jschmidt/work/org-mode/lisp/ob-sqlite hides /home/jschmidt/work/emacs-master/lisp/org/ob-sqlite
/home/jschmidt/work/org-mode/lisp/ob-clojure hides /home/jschmidt/work/emacs-master/lisp/org/ob-clojure
/home/jschmidt/work/org-mode/lisp/org-indent hides /home/jschmidt/work/emacs-master/lisp/org/org-indent
/home/jschmidt/work/org-mode/lisp/org-persist hides /home/jschmidt/work/emacs-master/lisp/org/org-persist
/home/jschmidt/work/org-mode/lisp/ol-eww hides /home/jschmidt/work/emacs-master/lisp/org/ol-eww
/home/jschmidt/work/org-mode/lisp/ol-info hides /home/jschmidt/work/emacs-master/lisp/org/ol-info
/home/jschmidt/work/org-mode/lisp/ol-rmail hides /home/jschmidt/work/emacs-master/lisp/org/ol-rmail
/home/jschmidt/work/org-mode/lisp/oc-basic hides /home/jschmidt/work/emacs-master/lisp/org/oc-basic
/home/jschmidt/work/org-mode/lisp/ob-forth hides /home/jschmidt/work/emacs-master/lisp/org/ob-forth
/home/jschmidt/work/org-mode/lisp/org-timer hides /home/jschmidt/work/emacs-master/lisp/org/org-timer
/home/jschmidt/work/org-mode/lisp/ob-makefile hides /home/jschmidt/work/emacs-master/lisp/org/ob-makefile
/home/jschmidt/work/org-mode/lisp/ob-fortran hides /home/jschmidt/work/emacs-master/lisp/org/ob-fortran
/home/jschmidt/work/org-mode/lisp/ox-html hides /home/jschmidt/work/emacs-master/lisp/org/ox-html
/home/jschmidt/work/org-mode/lisp/ob-lob hides /home/jschmidt/work/emacs-master/lisp/org/ob-lob
/home/jschmidt/work/org-mode/lisp/org-plot hides /home/jschmidt/work/emacs-master/lisp/org/org-plot
/home/jschmidt/work/org-mode/lisp/ob-js hides /home/jschmidt/work/emacs-master/lisp/org/ob-js
/home/jschmidt/work/org-mode/lisp/ob-R hides /home/jschmidt/work/emacs-master/lisp/org/ob-R
/home/jschmidt/work/org-mode/lisp/org-inlinetask hides /home/jschmidt/work/emacs-master/lisp/org/org-inlinetask
/home/jschmidt/work/org-mode/lisp/ol-mhe hides /home/jschmidt/work/emacs-master/lisp/org/ol-mhe
/home/jschmidt/work/org-mode/lisp/ob-dot hides /home/jschmidt/work/emacs-master/lisp/org/ob-dot
/home/jschmidt/work/org-mode/lisp/ol-docview hides /home/jschmidt/work/emacs-master/lisp/org/ol-docview
/home/jschmidt/work/org-mode/lisp/ob-C hides /home/jschmidt/work/emacs-master/lisp/org/ob-C
/home/jschmidt/work/org-mode/lisp/ol-man hides /home/jschmidt/work/emacs-master/lisp/org/ol-man
/home/jschmidt/work/org-mode/lisp/org-cycle hides /home/jschmidt/work/emacs-master/lisp/org/org-cycle
/home/jschmidt/work/org-mode/lisp/org-pcomplete hides /home/jschmidt/work/emacs-master/lisp/org/org-pcomplete
/home/jschmidt/work/org-mode/lisp/org-faces hides /home/jschmidt/work/emacs-master/lisp/org/org-faces
/home/jschmidt/work/org-mode/lisp/org hides /home/jschmidt/work/emacs-master/lisp/org/org
/home/jschmidt/work/org-mode/lisp/ol hides /home/jschmidt/work/emacs-master/lisp/org/ol
/home/jschmidt/work/org-mode/lisp/ob-haskell hides /home/jschmidt/work/emacs-master/lisp/org/ob-haskell
/home/jschmidt/work/org-mode/lisp/ob-lisp hides /home/jschmidt/work/emacs-master/lisp/org/ob-lisp
/home/jschmidt/work/org-mode/lisp/org-mobile hides /home/jschmidt/work/emacs-master/lisp/org/org-mobile
/home/jschmidt/work/org-mode/lisp/org-agenda hides /home/jschmidt/work/emacs-master/lisp/org/org-agenda
/home/jschmidt/work/org-mode/lisp/ob-perl hides /home/jschmidt/work/emacs-master/lisp/org/ob-perl
/home/jschmidt/work/org-mode/lisp/org-lint hides /home/jschmidt/work/emacs-master/lisp/org/org-lint
/home/jschmidt/work/org-mode/lisp/org-id hides /home/jschmidt/work/emacs-master/lisp/org/org-id
/home/jschmidt/work/org-mode/lisp/ox-man hides /home/jschmidt/work/emacs-master/lisp/org/ox-man
/home/jschmidt/work/org-mode/lisp/ol-bbdb hides /home/jschmidt/work/emacs-master/lisp/org/ol-bbdb
/home/jschmidt/work/org-mode/lisp/ob-lilypond hides /home/jschmidt/work/emacs-master/lisp/org/ob-lilypond
/home/jschmidt/work/org-mode/lisp/org-archive hides /home/jschmidt/work/emacs-master/lisp/org/org-archive
/home/jschmidt/work/org-mode/lisp/ox-publish hides /home/jschmidt/work/emacs-master/lisp/org/ox-publish
/home/jschmidt/work/org-mode/lisp/ob-core hides /home/jschmidt/work/emacs-master/lisp/org/ob-core
/home/jschmidt/work/org-mode/lisp/ob-groovy hides /home/jschmidt/work/emacs-master/lisp/org/ob-groovy
/home/jschmidt/work/org-mode/lisp/ox-org hides /home/jschmidt/work/emacs-master/lisp/org/ox-org
/home/jschmidt/work/org-mode/lisp/org-entities hides /home/jschmidt/work/emacs-master/lisp/org/org-entities
/home/jschmidt/work/org-mode/lisp/org-goto hides /home/jschmidt/work/emacs-master/lisp/org/org-goto
/home/jschmidt/work/org-mode/lisp/ob-awk hides /home/jschmidt/work/emacs-master/lisp/org/ob-awk
/home/jschmidt/work/org-mode/lisp/ol-eshell hides /home/jschmidt/work/emacs-master/lisp/org/ol-eshell
/home/jschmidt/work/org-mode/lisp/org-num hides /home/jschmidt/work/emacs-master/lisp/org/org-num
/home/jschmidt/work/org-mode/lisp/oc-csl hides /home/jschmidt/work/emacs-master/lisp/org/oc-csl
/home/jschmidt/work/org-mode/lisp/org-capture hides /home/jschmidt/work/emacs-master/lisp/org/org-capture
/home/jschmidt/work/org-mode/lisp/ob-ref hides /home/jschmidt/work/emacs-master/lisp/org/ob-ref
/home/jschmidt/work/org-mode/lisp/org-list hides /home/jschmidt/work/emacs-master/lisp/org/org-list
/home/jschmidt/work/org-mode/lisp/org-macro hides /home/jschmidt/work/emacs-master/lisp/org/org-macro
/home/jschmidt/work/org-mode/lisp/org-clock hides /home/jschmidt/work/emacs-master/lisp/org/org-clock
/home/jschmidt/work/org-mode/lisp/ob-table hides /home/jschmidt/work/emacs-master/lisp/org/ob-table
/home/jschmidt/work/org-mode/lisp/org-datetree hides /home/jschmidt/work/emacs-master/lisp/org/org-datetree
/home/jschmidt/work/org-mode/lisp/org-mouse hides /home/jschmidt/work/emacs-master/lisp/org/org-mouse
/home/jschmidt/work/org-mode/lisp/ob-latex hides /home/jschmidt/work/emacs-master/lisp/org/ob-latex
/home/jschmidt/work/org-mode/lisp/org-keys hides /home/jschmidt/work/emacs-master/lisp/org/org-keys
/home/jschmidt/work/org-mode/lisp/org-compat hides /home/jschmidt/work/emacs-master/lisp/org/org-compat
/home/jschmidt/work/org-mode/lisp/org-habit hides /home/jschmidt/work/emacs-master/lisp/org/org-habit
/home/jschmidt/work/org-mode/lisp/org-tempo hides /home/jschmidt/work/emacs-master/lisp/org/org-tempo
/home/jschmidt/work/org-mode/lisp/org-refile hides /home/jschmidt/work/emacs-master/lisp/org/org-refile
/home/jschmidt/work/org-mode/lisp/ob-ruby hides /home/jschmidt/work/emacs-master/lisp/org/ob-ruby
/home/jschmidt/work/org-mode/lisp/org-attach-git hides /home/jschmidt/work/emacs-master/lisp/org/org-attach-git
/home/jschmidt/work/org-mode/lisp/org-loaddefs hides /home/jschmidt/work/emacs-master/lisp/org/org-loaddefs
/home/jschmidt/work/org-mode/lisp/org-duration hides /home/jschmidt/work/emacs-master/lisp/org/org-duration
/home/jschmidt/work/org-mode/lisp/ob-ocaml hides /home/jschmidt/work/emacs-master/lisp/org/ob-ocaml
/home/jschmidt/work/org-mode/lisp/org-fold hides /home/jschmidt/work/emacs-master/lisp/org/org-fold
/home/jschmidt/work/org-mode/lisp/ox-ascii hides /home/jschmidt/work/emacs-master/lisp/org/ox-ascii
/home/jschmidt/work/org-mode/lisp/ob-css hides /home/jschmidt/work/emacs-master/lisp/org/ob-css
/home/jschmidt/work/org-mode/lisp/ob-tangle hides /home/jschmidt/work/emacs-master/lisp/org/ob-tangle
/home/jschmidt/work/org-mode/lisp/ob-python hides /home/jschmidt/work/emacs-master/lisp/org/ob-python
/home/jschmidt/work/org-mode/lisp/org-crypt hides /home/jschmidt/work/emacs-master/lisp/org/org-crypt
/home/jschmidt/work/org-mode/lisp/ol-bibtex hides /home/jschmidt/work/emacs-master/lisp/org/ol-bibtex
/home/jschmidt/work/org-mode/lisp/oc-biblatex hides /home/jschmidt/work/emacs-master/lisp/org/oc-biblatex
/home/jschmidt/work/org-mode/lisp/org-protocol hides /home/jschmidt/work/emacs-master/lisp/org/org-protocol
/home/jschmidt/work/org-mode/lisp/org-feed hides /home/jschmidt/work/emacs-master/lisp/org/org-feed
/home/jschmidt/work/org-mode/lisp/ob-maxima hides /home/jschmidt/work/emacs-master/lisp/org/ob-maxima
/home/jschmidt/work/org-mode/lisp/org-colview hides /home/jschmidt/work/emacs-master/lisp/org/org-colview
/home/jschmidt/work/org-mode/lisp/ol-w3m hides /home/jschmidt/work/emacs-master/lisp/org/ol-w3m
/home/jschmidt/work/org-mode/lisp/ob-ditaa hides /home/jschmidt/work/emacs-master/lisp/org/ob-ditaa
/home/jschmidt/work/org-mode/lisp/ob-plantuml hides /home/jschmidt/work/emacs-master/lisp/org/ob-plantuml
/home/jschmidt/work/org-mode/lisp/org-src hides /home/jschmidt/work/emacs-master/lisp/org/org-src
/home/jschmidt/work/org-mode/lisp/ob-sed hides /home/jschmidt/work/emacs-master/lisp/org/ob-sed
/home/jschmidt/work/org-mode/lisp/ox-latex hides /home/jschmidt/work/emacs-master/lisp/org/ox-latex
/home/jschmidt/work/org-mode/lisp/ob-exp hides /home/jschmidt/work/emacs-master/lisp/org/ob-exp
/home/jschmidt/work/org-mode/lisp/ob-lua hides /home/jschmidt/work/emacs-master/lisp/org/ob-lua
/home/jschmidt/work/org-mode/lisp/ox hides /home/jschmidt/work/emacs-master/lisp/org/ox
/home/jschmidt/work/org-mode/lisp/org-footnote hides /home/jschmidt/work/emacs-master/lisp/org/org-footnote
/home/jschmidt/work/org-mode/lisp/ol-doi hides /home/jschmidt/work/emacs-master/lisp/org/ol-doi
/home/jschmidt/work/org-mode/lisp/ob-emacs-lisp hides /home/jschmidt/work/emacs-master/lisp/org/ob-emacs-lisp
/home/jschmidt/work/org-mode/lisp/ox-odt hides /home/jschmidt/work/emacs-master/lisp/org/ox-odt
/home/jschmidt/work/org-mode/lisp/ob-eval hides /home/jschmidt/work/emacs-master/lisp/org/ob-eval
/home/jschmidt/work/org-mode/lisp/ob-matlab hides /home/jschmidt/work/emacs-master/lisp/org/ob-matlab
/home/jschmidt/work/org-mode/lisp/ob-sass hides /home/jschmidt/work/emacs-master/lisp/org/ob-sass
/home/jschmidt/work/org-mode/lisp/ob-java hides /home/jschmidt/work/emacs-master/lisp/org/ob-java
/home/jschmidt/work/org-mode/lisp/ob-julia hides /home/jschmidt/work/emacs-master/lisp/org/ob-julia
/home/jschmidt/work/org-mode/lisp/org-version hides /home/jschmidt/work/emacs-master/lisp/org/org-version
/home/jschmidt/work/org-mode/lisp/ob-calc hides /home/jschmidt/work/emacs-master/lisp/org/ob-calc
/home/jschmidt/work/org-mode/lisp/org-table hides /home/jschmidt/work/emacs-master/lisp/org/org-table
/home/jschmidt/work/org-mode/lisp/ol-irc hides /home/jschmidt/work/emacs-master/lisp/org/ol-irc
/home/jschmidt/work/org-mode/lisp/ob-eshell hides /home/jschmidt/work/emacs-master/lisp/org/ob-eshell
/home/jschmidt/work/org-mode/lisp/org-fold-core hides /home/jschmidt/work/emacs-master/lisp/org/org-fold-core
/home/jschmidt/work/org-mode/lisp/org-macs hides /home/jschmidt/work/emacs-master/lisp/org/org-macs
/home/jschmidt/work/org-mode/lisp/ob-comint hides /home/jschmidt/work/emacs-master/lisp/org/ob-comint
/home/jschmidt/work/org-mode/lisp/ox-texinfo hides /home/jschmidt/work/emacs-master/lisp/org/ox-texinfo
/home/jschmidt/work/org-mode/lisp/oc-natbib hides /home/jschmidt/work/emacs-master/lisp/org/oc-natbib
/home/jschmidt/work/org-mode/lisp/ob-screen hides /home/jschmidt/work/emacs-master/lisp/org/ob-screen
/home/jschmidt/work/org-mode/lisp/ox-beamer hides /home/jschmidt/work/emacs-master/lisp/org/ox-beamer
/home/jschmidt/work/org-mode/lisp/ob-octave hides /home/jschmidt/work/emacs-master/lisp/org/ob-octave
/home/jschmidt/work/org-mode/lisp/ob hides /home/jschmidt/work/emacs-master/lisp/org/ob
/home/jschmidt/work/org-mode/lisp/ob-shell hides /home/jschmidt/work/emacs-master/lisp/org/ob-shell
/home/jschmidt/work/org-mode/lisp/ox-md hides /home/jschmidt/work/emacs-master/lisp/org/ox-md
/home/jschmidt/work/org-mode/lisp/oc hides /home/jschmidt/work/emacs-master/lisp/org/oc
/home/jschmidt/work/org-mode/lisp/org-ctags hides /home/jschmidt/work/emacs-master/lisp/org/org-ctags
Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils compile text-property-search comint
ansi-osc ansi-color ring comp-run comp-common rx time delsel cus-load
advice finder-inf git-commit-autoloads magit-section-autoloads
simple-httpd-autoloads transient-autoloads info compat-autoloads
xr-autoloads yaml-mode-autoloads package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen 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 nadvice seq simple cl-generic indonesian philippine
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 abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)
Memory information:
((conses 16 131427 11427) (symbols 48 10928 0)
(strings 32 40700 4994) (string-bytes 1 1376609)
(vectors 16 23122) (vector-slots 8 386746 15291)
(floats 8 39 21) (intervals 56 278 0) (buffers 984 11))
^ permalink raw reply related [flat|nested] 19+ messages in thread* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 21:08 bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-26 21:23 ` Dmitry Gutov
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:05 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Dmitry Gutov @ 2023-11-26 21:23 UTC (permalink / raw)
To: Jens Schmidt, 67462
On 26/11/2023 23:08, Jens Schmidt via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
> diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
> index 37c54a90f42..1bb2b678d94 100644
> --- a/lisp/progmodes/prog-mode.el
> +++ b/lisp/progmodes/prog-mode.el
> @@ -163,7 +163,8 @@ prog-fill-reindent-defun
> (treesit-parser-list)
> (treesit-node-match-p
> (treesit-node-at (point)) 'text t))))
> - (if (or treesit-text-node
> + (if (or (local-variable-p 'fill-paragraph-function)
> + treesit-text-node
> (nth 8 (syntax-ppss))
> (re-search-forward "\\s-*\\s<" (line-end-position) t))
> (fill-paragraph argument (region-active-p))
I'm not sure this is going to work well because c-mode (for example)
also has a buffer-local value of fill-paragraph-function.
makefile-mode does look special in this regard. Perhaps it's one of
those modes that don't really use indentation in the same way as an
average "prog mode" does.
Maybe makefile-mode-map should simply rebind "M-q" back to 'fill-paragraph'.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 21:23 ` Dmitry Gutov
@ 2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:16 ` Eli Zaretskii
` (2 more replies)
2023-11-27 12:05 ` Eli Zaretskii
1 sibling, 3 replies; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-26 22:52 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 67462
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 26/11/2023 23:08, Jens Schmidt via Bug reports for GNU Emacs,
> the Swiss army knife of text editors wrote:
>> diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
>> index 37c54a90f42..1bb2b678d94 100644
>> --- a/lisp/progmodes/prog-mode.el
>> +++ b/lisp/progmodes/prog-mode.el
>> @@ -163,7 +163,8 @@ prog-fill-reindent-defun
>> (treesit-parser-list)
>> (treesit-node-match-p
>> (treesit-node-at (point)) 'text t))))
>> - (if (or treesit-text-node
>> + (if (or (local-variable-p 'fill-paragraph-function)
>> + treesit-text-node
>> (nth 8 (syntax-ppss))
>> (re-search-forward "\\s-*\\s<" (line-end-position) t))
>> (fill-paragraph argument (region-active-p))
>
> I'm not sure this is going to work well because c-mode (for
> example) also has a buffer-local value of
> fill-paragraph-function.
Uh. Good point.
> makefile-mode does look special in this regard. Perhaps it's one
> of those modes that don't really use indentation in the same way
> as an average "prog mode" does.
>
> Maybe makefile-mode-map should simply rebind "M-q" back to 'fill-paragraph'.
I tried a cursory grep '(defun .*-fill-paragraph' in lisp/progmodes/.el.
The following functions all seem to work outside of comments:
cfengine-fill-paragraph
f90-fill-paragraph
fortran-fill-paragraph
makefile-fill-paragraph
octave-fill-paragraph
I could be wrong with that list, though, and I cannot tell how useful
these functions are outside of comments. I just looked at docstrings or
for a prominent
(or (fill-comment-paragraph justify)
(do-something ...))
pattern.
Finally, there is `python-fill-paragraph', which tries to be smart
w.r.t. context. Not sure how its behavior outside of comments compares
to the one provided by `prog-fill-reindent-defun'.
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 12:16 ` Eli Zaretskii
2023-11-27 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 17:02 ` Juri Linkov
2023-11-27 19:46 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2023-11-27 12:16 UTC (permalink / raw)
To: Jens Schmidt; +Cc: 67462, dmitry
> Cc: 67462@debbugs.gnu.org
> Date: Sun, 26 Nov 2023 23:52:00 +0100
> From: Jens Schmidt via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
> > Maybe makefile-mode-map should simply rebind "M-q" back to 'fill-paragraph'.
>
> I tried a cursory grep '(defun .*-fill-paragraph' in lisp/progmodes/.el.
> The following functions all seem to work outside of comments:
>
> cfengine-fill-paragraph
> f90-fill-paragraph
> fortran-fill-paragraph
> makefile-fill-paragraph
> octave-fill-paragraph
>
> I could be wrong with that list, though, and I cannot tell how useful
> these functions are outside of comments. I just looked at docstrings or
> for a prominent
>
> (or (fill-comment-paragraph justify)
> (do-something ...))
>
> pattern.
What would it take to teach prog-fill-reindent-defun to DTRT outside
comments and strings?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 12:16 ` Eli Zaretskii
@ 2023-11-27 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:40 ` Dmitry Gutov
2023-11-27 20:55 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-27 20:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67462, dmitry
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: 67462@debbugs.gnu.org
>> Date: Sun, 26 Nov 2023 23:52:00 +0100
>> From: Jens Schmidt via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>> > Maybe makefile-mode-map should simply rebind "M-q" back to 'fill-paragraph'.
>>
>> I tried a cursory grep '(defun .*-fill-paragraph' in lisp/progmodes/.el.
>> The following functions all seem to work outside of comments:
>>
>> cfengine-fill-paragraph
>> f90-fill-paragraph
>> fortran-fill-paragraph
>> makefile-fill-paragraph
>> octave-fill-paragraph
>>
>> I could be wrong with that list, though, and I cannot tell how useful
>> these functions are outside of comments. I just looked at docstrings or
>> for a prominent
>>
>> (or (fill-comment-paragraph justify)
>> (do-something ...))
>>
>> pattern.
>
> What would it take to teach prog-fill-reindent-defun to DTRT outside
> comments and strings?
IMO the problem here is that some modes already have an idea of what
could be TRT outside comments and strings, implemented in a
mode-specific fill-paragraph-function. prog-fill-reindent-defun per se
doesn't have that knowledge, since it currently always just reindents
outside comments and strings.
A very conservative aproach to keep that knowledge of such modes would
be something along the following lines:
diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
index 37c54a90f42..df5aa845ae3 100644
--- a/lisp/progmodes/prog-mode.el
+++ b/lisp/progmodes/prog-mode.el
@@ -163,7 +163,13 @@ prog-fill-reindent-defun
(treesit-parser-list)
(treesit-node-match-p
(treesit-node-at (point)) 'text t))))
- (if (or treesit-text-node
+ (if (or ;; Use `fill-paragraph-function' if bound locally,
+ ;; unless its declares to work on comments only.
+ (and (local-variable-p 'fill-paragraph-function)
+ (or (not (symbolp fill-paragraph-function))
+ (not (get fill-paragraph-function
+ 'fills-only-comments))))
+ treesit-text-node
(nth 8 (syntax-ppss))
(re-search-forward "\\s-*\\s<" (line-end-position) t))
(fill-paragraph argument (region-active-p))
That is, a mode using a specific fill-paragraph-function has to
explicitly declare (with property `fills-only-comments') that its
fill-paragraph-function only fills comments. Only then that mode would
use the new default indentation of prog-fill-reindent-defun outside
comments and strings.
So for javascript mode, for example, we would also need:
diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index 5a669fdbd42..5c1c1845378 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -2975,6 +2975,8 @@ js-fill-paragraph
(fill-paragraph-function #'c-fill-paragraph))
(c-fill-paragraph justify)))
+(put 'js-fill-paragraph 'fills-only-comments t)
+
(defun js-do-auto-fill ()
(let ((js--filling-paragraph t))
(c-do-auto-fill)))
^ permalink raw reply related [flat|nested] 19+ messages in thread* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 20:40 ` Dmitry Gutov
2023-11-28 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:55 ` Eli Zaretskii
1 sibling, 1 reply; 19+ messages in thread
From: Dmitry Gutov @ 2023-11-27 20:40 UTC (permalink / raw)
To: Jens Schmidt, Eli Zaretskii; +Cc: 67462
On 27/11/2023 22:08, Jens Schmidt wrote:
> A very conservative aproach to keep that knowledge of such modes would
> be something along the following lines:
Or a less conservative approach: rebind the key in all modes where its
clear that they handle the outside-of-comments refilling themselves.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 20:40 ` Dmitry Gutov
@ 2023-11-28 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-28 21:28 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 67462, Eli Zaretskii
Dmitry Gutov <dmitry@gutov.dev> writes:
> On 27/11/2023 22:08, Jens Schmidt wrote:
>> A very conservative aproach to keep that knowledge of such modes would
>> be something along the following lines:
>
> Or a less conservative approach: rebind the key in all modes
> where its clear that they handle the outside-of-comments
> refilling themselves.
Right. You basically propose an opt-out of a new feature (which *could*
break work flows), I propose an opt-in. IMO the opt-out would have the
disadvantage that all the major modes on *ELPA or elsewhere would not be
covered.
If we go for the opt-out, probably the NEWS entry for command
`prog-fill-reindent-defun' should be updated to mention that M-q could
be rebound to `fill-paragraph' should the new command not have the
desired effect? Or does that go without saying?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:40 ` Dmitry Gutov
@ 2023-11-27 20:55 ` Eli Zaretskii
2023-11-28 21:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2023-11-27 20:55 UTC (permalink / raw)
To: Jens Schmidt; +Cc: 67462, dmitry
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
> Date: Mon, 27 Nov 2023 21:08:32 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> cfengine-fill-paragraph
> >> f90-fill-paragraph
> >> fortran-fill-paragraph
> >> makefile-fill-paragraph
> >> octave-fill-paragraph
> >>
> >> I could be wrong with that list, though, and I cannot tell how useful
> >> these functions are outside of comments. I just looked at docstrings or
> >> for a prominent
> >>
> >> (or (fill-comment-paragraph justify)
> >> (do-something ...))
> >>
> >> pattern.
> >
> > What would it take to teach prog-fill-reindent-defun to DTRT outside
> > comments and strings?
(I meant "inside", sorry.)
> IMO the problem here is that some modes already have an idea of what
> could be TRT outside comments and strings, implemented in a
> mode-specific fill-paragraph-function.
But isn't filling inside comments and strings basically very similar
in these modes?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 20:55 ` Eli Zaretskii
@ 2023-11-28 21:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-28 21:41 ` Dmitry Gutov
2023-11-29 12:38 ` Eli Zaretskii
0 siblings, 2 replies; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-28 21:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67462, dmitry
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
>> Date: Mon, 27 Nov 2023 21:08:32 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >
>> > What would it take to teach prog-fill-reindent-defun to DTRT outside
>> > comments and strings?
>
> (I meant "inside", sorry.)
>
>> IMO the problem here is that some modes already have an idea of what
>> could be TRT outside comments and strings, implemented in a
>> mode-specific fill-paragraph-function.
>
> But isn't filling inside comments and strings basically very similar
> in these modes?
You lost me here, sorry.
*Inside* comments and strings I don't see any issues: In these the
result of M-q should be identical before or after commit b889eced4449
introduced function `prog-fill-reindent-defun'. Because inside comment
and strings `prog-fill-reindent-defun' just forwards to
`fill-paragraph'.
It's outside comment and strings where behavior can differ. Or where
behavior actually differs, as shown in my initial report.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-28 21:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-28 21:41 ` Dmitry Gutov
2023-11-29 12:38 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Dmitry Gutov @ 2023-11-28 21:41 UTC (permalink / raw)
To: Jens Schmidt, Eli Zaretskii; +Cc: 67462
On 28/11/2023 23:10, Jens Schmidt wrote:
> It's outside comment and strings where behavior can differ. Or where
> behavior actually differs, as shown in my initial report.
Could you perhaps study and summarize the useful parts of those modes'
fill-paragraph-function's outside of strings and comments?
Perhaps they are similar enough to what prog-fill-reindent-defun does
already. Or perhaps there's some useful bit of behavior that could be
promoted. Or maybe there is a specific step which differs in many of
them, which could be separately made customizable.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-28 21:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-28 21:41 ` Dmitry Gutov
@ 2023-11-29 12:38 ` Eli Zaretskii
2023-11-29 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2023-11-29 12:38 UTC (permalink / raw)
To: Jens Schmidt; +Cc: 67462, dmitry
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
> Date: Tue, 28 Nov 2023 22:10:13 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> >> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
> >> Date: Mon, 27 Nov 2023 21:08:32 +0100
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >
> >> > What would it take to teach prog-fill-reindent-defun to DTRT outside
> >> > comments and strings?
> >
> > (I meant "inside", sorry.)
> >
> >> IMO the problem here is that some modes already have an idea of what
> >> could be TRT outside comments and strings, implemented in a
> >> mode-specific fill-paragraph-function.
> >
> > But isn't filling inside comments and strings basically very similar
> > in these modes?
>
> You lost me here, sorry.
>
> *Inside* comments and strings I don't see any issues: In these the
> result of M-q should be identical before or after commit b889eced4449
> introduced function `prog-fill-reindent-defun'. Because inside comment
> and strings `prog-fill-reindent-defun' just forwards to
> `fill-paragraph'.
>
> It's outside comment and strings where behavior can differ. Or where
> behavior actually differs, as shown in my initial report.
And you are saying that prog-fill-reindent-defun cannot be easily
taught to DTRT outside of comments and strings, and that the only
feasible approach is to reuse the old mode-specific functions in that
case? I'm not sure I understand why is that, since the doc string of
prog-fill-reindent-defun says:
If the point is in a string or a comment, fill the paragraph that
contains point or follows point.
Otherwise, reindent the function definition that contains point
or follows point.
And its code does:
(if (or treesit-text-node
(nth 8 (syntax-ppss))
(re-search-forward "\\s-*\\s<" (line-end-position) t))
(fill-paragraph argument (region-active-p))
(beginning-of-defun)
(let ((start (point)))
(end-of-defun)
(indent-region start (point) nil))))))
So you are saying that indent-region doesn't do its job in some/many
major modes? Can we fix that? Or what am I missing now?
^ permalink raw reply [flat|nested] 19+ messages in thread* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-29 12:38 ` Eli Zaretskii
@ 2023-11-29 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-30 6:39 ` Eli Zaretskii
0 siblings, 1 reply; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-29 21:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 67462, dmitry
Eli Zaretskii <eliz@gnu.org> writes:
> So you are saying that indent-region doesn't do its job in some/many
> major modes? Can we fix that? Or what am I missing now?
No, indent-region does a good job and there is nothing to fix here. But
starting with Emacs 30 it does that job (also) on M-q, where previously
other functionality may have been bound.
To see the difference, please try executing in Emacs 29 vs master on
Emacs's own, configured Makefile:
./src/emacs -Q Makefile --eval '(search-forward "SUBDIR_MAKEFILES_IN")'
M-q
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-29 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-30 6:39 ` Eli Zaretskii
2023-11-30 20:40 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2023-11-30 6:39 UTC (permalink / raw)
To: Jens Schmidt; +Cc: 67462, dmitry
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
> Date: Wed, 29 Nov 2023 22:28:49 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > So you are saying that indent-region doesn't do its job in some/many
> > major modes? Can we fix that? Or what am I missing now?
>
> No, indent-region does a good job and there is nothing to fix here. But
> starting with Emacs 30 it does that job (also) on M-q, where previously
> other functionality may have been bound.
>
> To see the difference, please try executing in Emacs 29 vs master on
> Emacs's own, configured Makefile:
>
> ./src/emacs -Q Makefile --eval '(search-forward "SUBDIR_MAKEFILES_IN")'
> M-q
So the problem is that the new code does its job, just with different
results than the mode-specific fill-paragraph-function did in Emacs 29
and before? If so, perhaps we should offer a user option to let users
choose which method to use, because some might prefer the new
behavior?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-30 6:39 ` Eli Zaretskii
@ 2023-11-30 20:40 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-30 23:56 ` Dmitry Gutov
0 siblings, 1 reply; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-30 20:40 UTC (permalink / raw)
To: Eli Zaretskii, dmitry; +Cc: 67462
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>> Cc: 67462@debbugs.gnu.org, dmitry@gutov.dev
>> Date: Wed, 29 Nov 2023 22:28:49 +0100
>>
>> No, indent-region does a good job and there is nothing to fix here. But
>> starting with Emacs 30 it does that job (also) on M-q, where previously
>> other functionality may have been bound.
>>
>> To see the difference, please try executing in Emacs 29 vs master on
>> Emacs's own, configured Makefile:
>>
>> ./src/emacs -Q Makefile --eval '(search-forward "SUBDIR_MAKEFILES_IN")'
>> M-q
>
> So the problem is that the new code does its job, just with different
> results than the mode-specific fill-paragraph-function did in Emacs 29
> and before?
Yes.
> If so, perhaps we should offer a user option to let users choose which
> method to use, because some might prefer the new behavior?
I'd be fine with that, and also with making the new behavior the
default. A reference to that user option would also nicely complete the
NEWS entry, which IMO currently is a bit weak in mentioning the possible
consequences of the new feature.
Dmitry, what do you think?
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-30 20:40 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-30 23:56 ` Dmitry Gutov
0 siblings, 0 replies; 19+ messages in thread
From: Dmitry Gutov @ 2023-11-30 23:56 UTC (permalink / raw)
To: Jens Schmidt, Eli Zaretskii; +Cc: 67462
On 30/11/2023 22:40, Jens Schmidt wrote:
>> If so, perhaps we should offer a user option to let users choose which
>> method to use, because some might prefer the new behavior?
> I'd be fine with that, and also with making the new behavior the
> default. A reference to that user option would also nicely complete the
> NEWS entry, which IMO currently is a bit weak in mentioning the possible
> consequences of the new feature.
>
> Dmitry, what do you think?
I think we should try to see whether those custom functions are better,
and in which cases.
makefile-mode is actually an odd case because while it inherits from
prog-mode, it doesn't quite satisfy an informal definition of what
should be prog modes: its value of indent-line-function is
#'indent-to-left-margin, which looks more like a text mode.
As a consequence, prog-fill-reindent-defun usually does nothing good
outside of strings and comments in makefile-mode. Since I'm guessing the
idea of ceasing to derive from prog-mode right away is not going to fly,
we can add exceptions like this (with a docstring update, of course):
diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
index 37c54a90f42..1927de7de2c 100644
--- a/lisp/progmodes/prog-mode.el
+++ b/lisp/progmodes/prog-mode.el
@@ -165,7 +165,10 @@ prog-fill-reindent-defun
(treesit-node-at (point)) 'text t))))
(if (or treesit-text-node
(nth 8 (syntax-ppss))
- (re-search-forward "\\s-*\\s<" (line-end-position) t))
+ (re-search-forward "\\s-*\\s<" (line-end-position) t)
+ (memq indent-line-function
+ '(indent-relative
+ indent-to-left-margin)))
(fill-paragraph argument (region-active-p))
(beginning-of-defun)
(let ((start (point)))
or even just this:
diff --git a/lisp/progmodes/prog-mode.el b/lisp/progmodes/prog-mode.el
index 37c54a90f42..0ff3701f8fc 100644
--- a/lisp/progmodes/prog-mode.el
+++ b/lisp/progmodes/prog-mode.el
@@ -165,7 +165,8 @@ prog-fill-reindent-defun
(treesit-node-at (point)) 'text t))))
(if (or treesit-text-node
(nth 8 (syntax-ppss))
- (re-search-forward "\\s-*\\s<" (line-end-position) t))
+ (re-search-forward "\\s-*\\s<" (line-end-position) t)
+ (not beginning-of-defun-function))
(fill-paragraph argument (region-active-p))
(beginning-of-defun)
(let ((start (point)))
because defun navigation is not set up there either.
fortran, octave and cfengine, however, could use rebinding or user
options (I can't really form an opinion on which of the behaviors is
more useful). cfengine doesn't set fill-paragraph-function either, so
the required changes would be a little less trivial than for the others.
But using the prog-mode's binding by default is probably better for
consistency.
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:16 ` Eli Zaretskii
@ 2023-11-27 17:02 ` Juri Linkov
2023-11-27 19:46 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2 siblings, 0 replies; 19+ messages in thread
From: Juri Linkov @ 2023-11-27 17:02 UTC (permalink / raw)
To: 67462; +Cc: Dmitry Gutov, Jens Schmidt
> Finally, there is `python-fill-paragraph', which tries to be smart
> w.r.t. context. Not sure how its behavior outside of comments compares
> to the one provided by `prog-fill-reindent-defun'.
There are more problems with prog-fill-reindent-defun in bug#63790.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:16 ` Eli Zaretskii
2023-11-27 17:02 ` Juri Linkov
@ 2023-11-27 19:46 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:46 ` Dmitry Gutov
2 siblings, 1 reply; 19+ messages in thread
From: Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-27 19:46 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 67462
Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> I'm not sure this is going to work well because c-mode (for
>> example) also has a buffer-local value of
>> fill-paragraph-function.
>
> Uh. Good point.
Actually, I have to correct myself here: `c-mode', even though deriving
from `prog-mode', goes at lengths to not use the derived binding of M-q,
but rather binds it directly:
;; It doesn't suffice to put `c-fill-paragraph' on
;; `fill-paragraph-function' since `c-fill-paragraph' must be called
;; before any fill prefix adaption is done. E.g. `filladapt-mode'
;; replaces `fill-paragraph' and does the adaption before calling
;; `fill-paragraph-function', and we have to mask comments etc
;; before that. Also, `c-fill-paragraph' chains on to
;; `fill-paragraph' and the value on `fill-paragraph-function' to
;; do the actual filling work.
(substitute-key-definition 'fill-paragraph 'c-fill-paragraph
c-mode-base-map global-map)
So `prog-fill-reindent-defun' wouldn't be bound in `c-mode' buffers,
anyway. The same seems to hold for `awk-mode', `c++-mode' and probably
other modes in that family.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-27 19:46 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 20:46 ` Dmitry Gutov
0 siblings, 0 replies; 19+ messages in thread
From: Dmitry Gutov @ 2023-11-27 20:46 UTC (permalink / raw)
To: Jens Schmidt; +Cc: 67462
On 27/11/2023 21:46, Jens Schmidt wrote:
> Jens Schmidt<jschmidt4gnu@vodafonemail.de> writes:
>
>> Dmitry Gutov<dmitry@gutov.dev> writes:
>>
>>> I'm not sure this is going to work well because c-mode (for
>>> example) also has a buffer-local value of
>>> fill-paragraph-function.
>> Uh. Good point.
> Actually, I have to correct myself here: `c-mode', even though deriving
> from `prog-mode', goes at lengths to not use the derived binding of M-q,
> but rather binds it directly:
>
> ;; It doesn't suffice to put `c-fill-paragraph' on
> ;; `fill-paragraph-function' since `c-fill-paragraph' must be called
> ;; before any fill prefix adaption is done. E.g. `filladapt-mode'
> ;; replaces `fill-paragraph' and does the adaption before calling
> ;; `fill-paragraph-function', and we have to mask comments etc
> ;; before that. Also, `c-fill-paragraph' chains on to
> ;; `fill-paragraph' and the value on `fill-paragraph-function' to
> ;; do the actual filling work.
> (substitute-key-definition 'fill-paragraph 'c-fill-paragraph
> c-mode-base-map global-map)
>
> So `prog-fill-reindent-defun' wouldn't be bound in `c-mode' buffers,
> anyway. The same seems to hold for `awk-mode', `c++-mode' and probably
> other modes in that family.
Fair counterpoint.
We can take instead emacs-lisp-mode as an example: it has
fill-paragraph-function defined (lisp-fill-paragraph) which only works
in strings and comments.
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function
2023-11-26 21:23 ` Dmitry Gutov
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-27 12:05 ` Eli Zaretskii
1 sibling, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2023-11-27 12:05 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 67462, jschmidt4gnu
> Date: Sun, 26 Nov 2023 23:23:04 +0200
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> Maybe makefile-mode-map should simply rebind "M-q" back to 'fill-paragraph'.
Yes, I think it should.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-11-30 23:56 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-26 21:08 bug#67462: 30.0.50; prog-fill-reindent-defun does not respect buffer-local fill-paragraph-function Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26 21:23 ` Dmitry Gutov
2023-11-26 22:52 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 12:16 ` Eli Zaretskii
2023-11-27 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:40 ` Dmitry Gutov
2023-11-28 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:55 ` Eli Zaretskii
2023-11-28 21:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-28 21:41 ` Dmitry Gutov
2023-11-29 12:38 ` Eli Zaretskii
2023-11-29 21:28 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-30 6:39 ` Eli Zaretskii
2023-11-30 20:40 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-30 23:56 ` Dmitry Gutov
2023-11-27 17:02 ` Juri Linkov
2023-11-27 19:46 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-27 20:46 ` Dmitry Gutov
2023-11-27 12:05 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).