GNU bug report logs - #65797
`buffer-match-p` should not use `func-arity`

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 65797 in the body.
You can then email your comments to 65797 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.92; func-arity should not return (0 . many) with apply-partially
Date: Thu, 07 Sep 2023 00:53:07 -0700

Sorry, I accidentally sent an email about this to the emacs-devel list.

(func-arity (apply-partially #'eq 'foo))
  ⇒ (0 . many)

gives the impression that the following is valid:

(funcall (apply-partially #'eq 'foo) 'foo 'bar)
     error→ (wrong-number-of-arguments #<subr eq> 3)

Here's an example of where this bug comes up in real code.

This should return a list of buffers which locally bind foo:

(match-buffers (apply-partially #'local-variable-p 'foo))

but instead it signals an error:

Debugger entered--Lisp error: (wrong-number-of-arguments #<subr local-variable-p> 3)
local-variable-p(foo #<buffer *scratch*> nil)
apply(local-variable-p (foo #<buffer *scratch*> nil))
...

because buffer-match-p uses func-arity to conditionally apply ARG.

Sidenote - compat.el's buffer-match-p does this

(condition-case nil
    (funcall condition buffer)
  (wrong-number-of-arguments
   (funcall condition buffer arg)))

instead of

(if (eq 1 (cdr (func-arity condition)))
    (funcall condition buffer-or-name)
  (funcall condition buffer-or-name arg))

and is therefore immune to this bug.

Joseph

In GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure
 CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash
 --prefix=/gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92
 --enable-fast-install --with-modules --with-cairo
 --with-native-compilation --disable-build-details'

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 SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: /home/joseph/.guix-extra-profiles/emacs/emacs/share/emacs/site-lisp:/gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp
  value of $EMACSNATIVELOADPATH: /home/joseph/.guix-extra-profiles/emacs/emacs/lib/emacs/native-site-lisp
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: mu4e:view

Minor modes in effect:
  mu4e-search-minor-mode: t
  mu4e-context-minor-mode: t
  mu4e-modeline-mode: t
  repeat-mode: t
  pixel-scroll-precision-mode: t
  engine-mode: t
  ws-butler-global-mode: t
  ws-butler-mode: t
  diff-hl-flydiff-mode: t
  magit-todos-mode: t
  global-hl-todo-mode: t
  magit-wip-initial-backup-mode: t
  magit-wip-before-change-mode: t
  magit-wip-after-apply-mode: t
  magit-wip-after-save-mode: t
  magit-wip-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  whole-line-or-region-global-mode: t
  whole-line-or-region-local-mode: t
  corfu-history-mode: t
  global-corfu-mode: t
  corfu-mode: t
  marginalia-mode: t
  vertico-reverse-mode: t
  vertico-mode: t
  display-battery-mode: t
  display-time-mode: t
  global-aggressive-indent-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  pulsar-global-mode: t
  pulsar-mode: t
  desktop-environment-mode: t
  server-mode: t
  global-subword-mode: t
  subword-mode: t
  delete-selection-mode: t
  electric-pair-mode: t
  savehist-mode: t
  save-place-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
/home/joseph/.emacs.d/elpa/jabber/jabber-autoloads hides /home/joseph/.emacs.d/elpa/jabber/lisp/jabber-autoloads
/gnu/store/gfp1flcfi9yxrlg35mwh4xbssd4yix20-emacs-transient-0.4.3/share/emacs/site-lisp/transient-0.4.3/transient hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/transient
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-diminish hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-diminish
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-lint hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-lint
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-jump hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-jump
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-ensure hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-ensure
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/bind-key hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/bind-key
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-delight hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-delight
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-core hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-core
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-bind-key hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-bind-key
/gnu/store/r5w8fq8jznd21r8pzcvb0xb1zxl6y2sc-emacs-use-package-2.4.4/share/emacs/site-lisp/use-package-2.4.4/use-package-ensure-system-package hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/use-package/use-package-ensure-system-package
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc-csl hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc-csl
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-haskell hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-haskell
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-pcomplete hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-pcomplete
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-fortran hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-fortran
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-eval hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-eval
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-ascii hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-ascii
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-faces hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-faces
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-irc hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-irc
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-latex hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-latex
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc-biblatex hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc-biblatex
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-keys hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-keys
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-entities hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-entities
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-octave hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-octave
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-forth hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-forth
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-list hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-list
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-plantuml hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-plantuml
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-md hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-md
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-feed hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-feed
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-eshell hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-eshell
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-eww hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-eww
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-java hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-java
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-doi hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-doi
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-src hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-src
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-goto hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-goto
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-habit hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-habit
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-lisp hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-lisp
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-js hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-js
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-tangle hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-tangle
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-clojure hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-clojure
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-julia hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-julia
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-info hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-info
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-sqlite hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-sqlite
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-sed hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-sed
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-gnus hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-gnus
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-exp hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-exp
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-gnuplot hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-gnuplot
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-table hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-table
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-num hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-num
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-lilypond hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-lilypond
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-w3m hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-w3m
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-sql hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-sql
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-attach hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-attach
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-capture hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-capture
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-emacs-lisp hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-emacs-lisp
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-cycle hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-cycle
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-sass hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-sass
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-fold-core hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-fold-core
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-macs hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-macs
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-archive hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-archive
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-footnote hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-footnote
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-tempo hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-tempo
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-odt hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-odt
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-screen hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-screen
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-timer hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-timer
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-comint hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-comint
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-shell hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-shell
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-dot hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-dot
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-macro hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-macro
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-mhe hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-mhe
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc-bibtex hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc-bibtex
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-ruby hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-ruby
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-groovy hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-groovy
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc-basic hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc-basic
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-plot hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-plot
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-lua hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-lua
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-awk hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-awk
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-calc hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-calc
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-agenda hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-agenda
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-mobile hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-mobile
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-man hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-man
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-R hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-R
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-beamer hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-beamer
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-icalendar hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-icalendar
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-processing hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-processing
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-indent hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-indent
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-inlinetask hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-inlinetask
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/oc-natbib hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/oc-natbib
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-fold hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-fold
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-attach-git hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-attach-git
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-bibtex hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-bibtex
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-refile hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-refile
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-protocol hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-protocol
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-python hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-python
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-latex hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-latex
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-colview hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-colview
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-duration hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-duration
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-lob hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-lob
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-ocaml hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-ocaml
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-version hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-version
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-scheme hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-scheme
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-matlab hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-matlab
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-makefile hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-makefile
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-ref hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-ref
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-org hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-org
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-loaddefs hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-loaddefs
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-texinfo hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-texinfo
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-rmail hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-rmail
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-perl hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-perl
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-mouse hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-mouse
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-maxima hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-maxima
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-ditaa hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-ditaa
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-bbdb hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-bbdb
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-koma-letter hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-koma-letter
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-lint hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-lint
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-crypt hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-crypt
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-C hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-C
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-html hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-html
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-core hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-core
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-id hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-id
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-eshell hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-eshell
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-compat hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-compat
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ol-docview hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ol-docview
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-datetree hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-datetree
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-element hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-element
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-ctags hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-ctags
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-table hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-table
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-man hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-man
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-org hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-org
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-persist hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-persist
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ob-css hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ob-css
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/org-clock hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/org-clock
/gnu/store/l4x0hyy62q491djdwx995gnss4pklp93-emacs-org-9.6.8/share/emacs/site-lisp/org-9.6.8/ox-publish hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/org/ox-publish
/gnu/store/wpbwpy52q2n6khqjplndx33gvln1clii-emacs-soap-client-3.2.3/share/emacs/site-lisp/soap-client-3.2.3/soap-inspect hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/net/soap-inspect
/gnu/store/wpbwpy52q2n6khqjplndx33gvln1clii-emacs-soap-client-3.2.3/share/emacs/site-lisp/soap-client-3.2.3/soap-client hides /gnu/store/rsyqw1rk4qswgmi1yc7jryb4fmq56y9h-emacs-next-tree-sitter-29.0.92/share/emacs/29.0.92/lisp/net/soap-client

Features:
(shadow emacsbug compat-macs rect dabbrev help-at-pt tramp-cmds crux
tramp tramp-loaddefs trampver tramp-integration tramp-compat
tempel-collection tempel hyperdrive-history hyperdrive-mirror completion
xref edebug hyperdrive-dir magit-patch magit-subtree magit-gitignore
magit-ediff ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util embark-org embark-consult embark elisp-demos
shortdoc texinfo texinfo-loaddefs cl-print package-x help-fns hyperdrive
hyperdrive-org hyperdrive-ewoc hyperdrive-lib hyperdrive-vars plz
persist ert debug backtrace org-transclusion org-transclusion-font-lock
org-transclusion-src-lines text-clone ox-texinfo ox-odt rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table ox-ascii
ox-publish ox loaddefs-gen radix-tree network-stream url-cache url-http
url-auth url-gw nsm misc cus-edit cus-start package-vc lisp-mnt
org-archive cal-move ace-window avy dired-aux gnus-dired ledger-mode
ledger-check ledger-texi ledger-test ledger-sort ledger-report
ledger-reconcile ledger-occur ledger-fonts ledger-fontify ledger-state
ledger-complete ledger-schedule ledger-init ledger-xact ledger-post
ledger-exec ledger-navigate eshell esh-cmd esh-ext esh-opt esh-proc
esh-io esh-arg esh-module esh-groups esh-util files-x ledger-context
ledger-commodities ledger-regex vc-hg vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs bug-reference magit-extras org-clock undo-fu orderless
consult misearch multi-isearch qp cursor-sensor sort gnus-cite shr-color
mm-archive mail-extr textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check mu4e mu4e-org mu4e-notification
notifications mu4e-main mu4e-view mu4e-headers mu4e-compose mu4e-draft
mu4e-actions smtpmail mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark
mu4e-message flow-fill mule-util hl-line mu4e-contacts mu4e-update
mu4e-folders mu4e-context mu4e-query-items mu4e-server mu4e-modeline
mu4e-vars mu4e-helpers mu4e-config mu4e-window magit-bookmark bookmark
pp ido mu4e-obsolete elide-head diary-lib diary-loaddefs cal-iso vc-git
org-indent org-appear outli oc-basic ol-eww eww url-queue mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view
jka-compr image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi
org-link-doi face-remap topsy makem project repeat smartparens
dired-subtree dired-hacks-utils jabber jabber-time jabber-autoaway
jabber-vcard-avatars jabber-chatstates jabber-events jabber-vcard
jabber-avatar jabber-activity jabber-watch jabber-modeline
jabber-ahc-presence jabber-ahc jabber-version jabber-ourversion
jabber-muc-nick-completion hippie-exp jabber-muc jabber-bookmarks
jabber-muc-nick-coloring jabber-browse jabber-search jabber-register
jabber-widget jabber-chat jabber-history jabber-chatbuffer jabber-roster
jabber-carbons jabber-presence jabber-private jabber-logon jabber-conn
srv dns starttls jabber-core jabber-keepalive jabber-ping jabber-disco
jabber-iq jabber-console sgml-mode facemenu jabber-truncate jabber-alert
jabber-keymap jabber-sasl sasl sasl-anonymous sasl-login sasl-plain
jabber-menu jabber-util fsm jabber-xml goto-addr pixel-scroll cua-base
engine-mode ws-butler diff-hl-flydiff diff-hl log-view vc-dir ewoc vc
vc-dispatcher magit-todos pcre2el rxt advice re-builder hl-todo f s
async grep compile magit-submodule 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 diff-mode git-commit log-edit pcvs-util
add-log magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process with-editor magit-mode transient edmacro
magit-git magit-base magit-section crm dash auth-source-pass
whole-line-or-region corfu-history corfu marginalia vertico-reverse
vertico battery time aggressive-indent easy-mmode recentf tree-widget
no-littering compat compat-29 org-contacts org-capture gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill
kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus
gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time iso8601
gnus-spec gnus-int gnus-range message sendmail yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus nnheader
mail-utils range mm-util mail-prsvr wid-edit gnus-util
text-property-search org-agenda org-element org-persist xdg org-id
avl-tree generator org-refile org ob-dot ob-shell shell ob-js ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint
org-pcomplete pcomplete comint ansi-osc ansi-color ring org-list
org-footnote org-faces org-entities time-date noutline outline
ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc
org-loaddefs cal-menu calendar cal-loaddefs ol org-fold org-fold-core
org-compat org-version org-macs format-spec pulsar pulse color
desktop-environment dbus xml comp comp-cstr warnings icons cl-extra
help-mode exwm exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating
xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh
xcb-icccm xcb xcb-xproto xcb-types xcb-debug server
elfeed-tube-mpv-autoloads elfeed-tube-autoloads org-make-toc-autoloads
org-modern-autoloads org-ql-autoloads org-super-agenda-autoloads
ht-autoloads ts-autoloads cus-load setup kmacro org-bookmarks ffap
thingatpt cap-words superword subword modus-vivendi-theme modus-themes
pcase delsel elec-pair find-func savehist saveplace move-bank-csvs
wgrep-autoloads ws-butler-autoloads simple-httpd-autoloads
orderless-autoloads marginalia-autoloads diff-hl-autoloads
git-link-autoloads pcre2el-autoloads hl-todo-autoloads
magit-todos-autoloads interactive-align-autoloads
ace-window-breatheoutbreathein-autoloads ztree-autoloads
posframe-autoloads vertico-autoloads expand-region-autoloads
avy-autoloads embark-autoloads tempel-collection-autoloads
tempel-autoloads corfu-autoloads eat-autoloads sqlite3-api-autoloads
pg-autoloads finalize-autoloads emacsql-autoloads
emacsql-sqlite3-autoloads org-roam-autoloads consult-org-roam-autoloads
consult-dir-autoloads consult-autoloads eimp-autoloads
dired-hacks-autoloads org-appear-autoloads csv-mode-autoloads
ledger-mode-autoloads aggressive-indent-autoloads vundo-autoloads
undo-fu-autoloads crux-autoloads inspector-autoloads
soap-client-autoloads debbugs-autoloads markdown-mode-autoloads
smartparens-autoloads outli-breatheoutbreathein-autoloads
macrostep-autoloads nameless-autoloads shut-up-autoloads
spinner-autoloads loop-autoloads suggest-autoloads treepy-autoloads
elisp-demos-autoloads detached-autoloads tmr-autoloads f-autoloads
password-store-autoloads pass-autoloads disk-usage-autoloads
mpv-autoloads simple-mpc-breatheoutbreathein-autoloads kv-autoloads
esxml-autoloads nov-el-autoloads tablist-autoloads pdf-tools-autoloads
org-noter-autoloads s-autoloads elfeed-org-autoloads elfeed-autoloads
transmission-autoloads deferred-autoloads request-autoloads
webpaste-autoloads org-contacts-autoloads mu4e-autoloads
org-mime-autoloads org-present-autoloads org-autoloads
org-download-autoloads async-autoloads with-editor-autoloads
transient-autoloads magit-autoloads orgit-autoloads
org-cliplink-autoloads magit-popup-autoloads geiser-guile-autoloads
geiser-autoloads edit-indirect-autoloads dash-autoloads bui-autoloads
guix-autoloads rx pulsar-autoloads showtip-autoloads pos-tip-autoloads
popup-autoloads sdcv-autoloads nord-theme-autoloads compat-autoloads
no-littering-autoloads disable-mouse-autoloads engine-mode-autoloads
vterm-autoloads exwm-edit-autoloads desktop-environment-autoloads
xelb-autoloads exwm-autoloads setup-autoloads diminish-autoloads
use-package-autoloads guix-emacs aio-autoloads chordpro-mode-autoloads
emms-autoloads fsm-autoloads gemini-mode-autoloads hyperdrive-autoloads
jabber-autoloads org-timeblock-autoloads org-transclusion-autoloads
ov-autoloads peg-autoloads persist-autoloads pipewire-autoloads info
plz-autoloads srv-autoloads svg-tag-mode-autoloads svg-lib-autoloads
topsy-autoloads finder-inf ushin-shapes-autoloads
whole-line-or-region-autoloads xr-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 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 move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 1840338 193031)
 (symbols 48 65655 5)
 (strings 32 345161 25227)
 (string-bytes 1 14452803)
 (vectors 16 178178)
 (vector-slots 8 3960622 378098)
 (floats 8 987 1313)
 (intervals 56 74447 7074)
 (buffers 984 75))

Message #8 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: 65797 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: bug#65797: 29.0.92; func-arity should not return (0 . many) with
 apply-partially
Date: Thu, 7 Sep 2023 14:35:17 +0200

[Message part 1 (text/plain, inline)]

Here is one way, but it's mainly aimed at improving performance, not guaranteeing a particular function signature.

(Yet another reason to avoid using buffer-match-p as far as I'm concerned.)

[apply-partially.diff (application/octet-stream, attachment)]

Message #11 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Thu, 07 Sep 2023 09:43:54 -0400

> because buffer-match-p uses func-arity to conditionally apply ARG.

That's the bug.


        Stefan

Message #14 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Thu, 07 Sep 2023 11:11:29 -0400

> Here is one way, but it's mainly aimed at improving performance, not
> guaranteeing a particular function signature.

And it breaks if the calling convention of the function changes between
the time you compile the code and the time you run the code :-(


        Stefan

Message #17 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many) with
 apply-partially
Date: Thu, 7 Sep 2023 17:17:28 +0200

7 sep. 2023 kl. 17.11 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> And it breaks if the calling convention of the function changes between
> the time you compile the code and the time you run the code :-(

What can I say, if you wanted something that could easily be reasoned about statically you wouldn't use Lisp...

Nah, forget that patch. Anyone interested in performance shouldn't use apply-partially anyway.

Message #20 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Thu, 07 Sep 2023 11:50:16 -0400

retitle 65797 `buffer-match-p` should not use `func-arity`
thanks

> (match-buffers (apply-partially #'local-variable-p 'foo))

Note that this call is incorrect according to the docstring of
`buffer-match-p`, which says:

    CONDITION is either:
    [...]
    - a predicate function that takes BUFFER-OR-NAME and ARG as
      arguments, and returns non-nil if the buffer matches,

IOW, you have to pass a function that accepts 2 arguments, whereas your
(apply-partially #'local-variable-p 'foo) only accepts one.

The Texinfo docs instead say:

    @item
    A predicate function, which should return non-@code{nil} if the buffer
    matches.  If the function expects one argument, it is called with
    @var{buffer-or-name} as the argument; if it expects 2 arguments, the
    first argument is @var{buffer-or-name} and the second is @var{arg}
    (or @code{nil} if @var{arg} is omitted).

but in general we can't reliably decide whether "the function expects
one argument", so we can't implement the above promise in a reliable way.
`apply-partially` is just one case where this shows up, but the problem
is much more general.
`buffer-match-p` uses the `func-arity` hack to try to make it work with
some functions of 1 argument, but it's just a hack.

We should get rid of this hack.  Here are some possible replacements
(by order of my preference):

- Replace `&optional arg` with `&rest args` and pass those args via
  `apply`, so the number of args passed doesn't depend on the function
  but on the caller.
- Always pass both args to the function (i.e. as documented in the
  docstring).
- Get rid of `&optional arg` altogether.
  AFAICT, most callers don't use it, but it's used for
  `display-buffer-alist`, so it would have further consequences there :-(
- Use a hack like

      (condition-case nil (funcall condition buffer-or-name arg)
        (wrong-number-of-arguments (funcall condition buffer-or-name)))

  which handles the arity mismatch a bit more reliably, but at the cost of
  occasionally running the function twice.


        Stefan

Message #25 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Thu, 07 Sep 2023 21:40:28 -0700

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> - Replace `&optional arg` with `&rest args` and pass those args via
>   `apply`, so the number of args passed doesn't depend on the function
>   but on the caller.

I like this idea. See patch.

> - Always pass both args to the function (i.e. as documented in the
>   docstring).

This isn't backwards compatible, is it?

Joseph

[0001-Don-t-use-func-arity-in-buffer-match-p.patch (text/x-diff, attachment)]

Message #28 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: monnier <at> iro.umontreal.ca, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92;
 func-arity should not return (0 . many) with apply-partially
Date: Fri, 08 Sep 2023 09:46:15 +0300

> Cc: 65797 <at> debbugs.gnu.org
> Date: Thu, 07 Sep 2023 21:40:28 -0700
> From:  Joseph Turner via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> > - Replace `&optional arg` with `&rest args` and pass those args via
> >   `apply`, so the number of args passed doesn't depend on the function
> >   but on the caller.
> 
> I like this idea. See patch.
> 
> > - Always pass both args to the function (i.e. as documented in the
> >   docstring).
> 
> This isn't backwards compatible, is it?

Neither is what you propose, AFAIU.  We are in effect changing a
public API in incompatible ways.

Message #31 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Fri, 08 Sep 2023 11:52:25 -0400

>> This isn't backwards compatible, is it?
> Neither is what you propose, AFAIU.  We are in effect changing a
> public API in incompatible ways.

Yup, AFAICT there's no way to implement the Texinfo-documented
behavior reliably.

So some backward-incompatibility is inevitable, unless we decide to
stick to the current code to be "bug compatible" :-(


        Stefan

Message #34 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many) with apply-partially
Date: Fri, 08 Sep 2023 09:37:18 -0700

On September 8, 2023 8:52:25 AM PDT, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>>> This isn't backwards compatible, is it?
>> Neither is what you propose, AFAIU.  We are in effect changing a
>> public API in incompatible ways.
>
>Yup, AFAICT there's no way to implement the Texinfo-documented
>behavior reliably.
>
>So some backward-incompatibility is inevitable, unless we decide to
>stick to the current code to be "bug compatible" 

IIUC, the patch breaks code that passes a CONDITION predicate that accepts only one argument and also passes an ARG argument.

Is there another case which would break?

Message #37 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 08 Sep 2023 17:01:50 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> retitle 65797 `buffer-match-p` should not use `func-arity`
> thanks
>
>> (match-buffers (apply-partially #'local-variable-p 'foo))
>
> Note that this call is incorrect according to the docstring of
> `buffer-match-p`, which says:
>
>     CONDITION is either:
>     [...]
>     - a predicate function that takes BUFFER-OR-NAME and ARG as
>       arguments, and returns non-nil if the buffer matches,
>
> IOW, you have to pass a function that accepts 2 arguments, whereas your
> (apply-partially #'local-variable-p 'foo) only accepts one.
>
> The Texinfo docs instead say:
>
>     @item
>     A predicate function, which should return non-@code{nil} if the buffer
>     matches.  If the function expects one argument, it is called with
>     @var{buffer-or-name} as the argument; if it expects 2 arguments, the
>     first argument is @var{buffer-or-name} and the second is @var{arg}
>     (or @code{nil} if @var{arg} is omitted).
>
> but in general we can't reliably decide whether "the function expects
> one argument", so we can't implement the above promise in a reliable way.
> `apply-partially` is just one case where this shows up, but the problem
> is much more general.
> `buffer-match-p` uses the `func-arity` hack to try to make it work with
> some functions of 1 argument, but it's just a hack.
>
> We should get rid of this hack.  Here are some possible replacements
> (by order of my preference):
>
> - Replace `&optional arg` with `&rest args` and pass those args via
>   `apply`, so the number of args passed doesn't depend on the function
>   but on the caller.
> - Always pass both args to the function (i.e. as documented in the
>   docstring).
> - Get rid of `&optional arg` altogether.
>   AFAICT, most callers don't use it, but it's used for
>   `display-buffer-alist`, so it would have further consequences there :-(

FWIW The intention here was to be able and specify simpler conditions
that don't have to handle the alist.

> - Use a hack like
>
>       (condition-case nil (funcall condition buffer-or-name arg)
>         (wrong-number-of-arguments (funcall condition buffer-or-name)))
>
>   which handles the arity mismatch a bit more reliably, but at the cost of
>   occasionally running the function twice.
>
>
>         Stefan

Message #40 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Fri, 08 Sep 2023 13:18:55 -0400

> IIUC, the patch breaks code that passes a CONDITION predicate that accepts
> only one argument and also passes an ARG argument.
>
> Is there another case which would break?

Yes, it also breaks the reverse: when you don't pass ARG but the
function needs 2 arguments.


        Stefan

Message #43 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Fri, 08 Sep 2023 11:16:26 -0700

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> IIUC, the patch breaks code that passes a CONDITION predicate that accepts
>> only one argument and also passes an ARG argument.
>>
>> Is there another case which would break?
>
> Yes, it also breaks the reverse: when you don't pass ARG but the
> function needs 2 arguments.
>
>
>         Stefan

You are right.

Message #46 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Fri, 08 Sep 2023 21:20:13 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Joseph Turner <joseph <at> breatheoutbreathe.in>,  65797 <at> debbugs.gnu.org
> Date: Fri, 08 Sep 2023 11:52:25 -0400
> 
> >> This isn't backwards compatible, is it?
> > Neither is what you propose, AFAIU.  We are in effect changing a
> > public API in incompatible ways.
> 
> Yup, AFAICT there's no way to implement the Texinfo-documented
> behavior reliably.
> 
> So some backward-incompatibility is inevitable, unless we decide to
> stick to the current code to be "bug compatible" :-(

I think one of the alternatives you proposed was backward-compatible
(albeit not very elegant).  So my vote is for that alternative.

Message #49 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Mon, 11 Sep 2023 09:57:51 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think one of the alternatives you proposed was backward-compatible
> (albeit not very elegant).  So my vote is for that alternative.

I'm in favor of the solution in the patch (from Stefan's suggestion):

> - Replace `&optional arg` with `&rest args` and pass those args via
>   `apply`, so the number of args passed doesn't depend on the function
>   but on the caller.

The "&rest args" solution is clean and hack-free. It breaks
compatibility, but in unlikely cases:

- CONDITION pred accepts only a buffer argument, but additional ARG was
  passed (why would you do this?)

- CONDITION pred accepts two arguments, and no ARG was passed (this code
  would be broken anyway, right?)

Since buffer-match-p is new in Emacs 29, is it acceptable to assume that
code affected by this breakage can be updated?

Joseph

Message #52 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: monnier <at> iro.umontreal.ca, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Mon, 11 Sep 2023 21:58:26 +0300

> From: Joseph Turner <joseph <at> breatheoutbreathe.in>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
> Date: Mon, 11 Sep 2023 09:57:51 -0700
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think one of the alternatives you proposed was backward-compatible
> > (albeit not very elegant).  So my vote is for that alternative.
> 
> I'm in favor of the solution in the patch (from Stefan's suggestion):
> 
> > - Replace `&optional arg` with `&rest args` and pass those args via
> >   `apply`, so the number of args passed doesn't depend on the function
> >   but on the caller.
> 
> The "&rest args" solution is clean and hack-free. It breaks
> compatibility, but in unlikely cases:
> 
> - CONDITION pred accepts only a buffer argument, but additional ARG was
>   passed (why would you do this?)
> 
> - CONDITION pred accepts two arguments, and no ARG was passed (this code
>   would be broken anyway, right?)
> 
> Since buffer-match-p is new in Emacs 29, is it acceptable to assume that
> code affected by this breakage can be updated?

We have an alternative that doesn't break any compatibility, so I
think it is preferred.

Message #55 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Tue, 12 Sep 2023 14:28:13 -0400

> FWIW The intention here was to be able and specify simpler conditions
> that don't have to handle the alist.

You mean for `display-buffer-alist`?
Do you have examples that rely on this?


        Stefan

Message #58 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65797 <at> debbugs.gnu.org, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: 29.0.92; func-arity should not return (0 . many)
 with apply-partially
Date: Tue, 12 Sep 2023 14:30:45 -0400

>> So some backward-incompatibility is inevitable, unless we decide to
>> stick to the current code to be "bug compatible" :-(
> I think one of the alternatives you proposed was backward-compatible
> (albeit not very elegant).  So my vote is for that alternative.

I'd first want to decide which semantics we want to document.
We could keep the current semantics, but since we're unable to implement it
reliably I'd rather we change it.

After that we can decide on how to preserve backward compatibility (for
which it would be OK to rely on a hack like the current one).

Maybe the simplest change is to align the Texinfo doc with the docstring
(i.e. document that two args are passed, always) and keep the code as
is.  And maybe tweak the code so it emits a warning when

    (eq 1 (cdr (func-arity condition)))

is true.


        Stefan

Message #61 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Wed, 13 Sep 2023 21:50:27 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> FWIW The intention here was to be able and specify simpler conditions
>> that don't have to handle the alist.
>
> You mean for `display-buffer-alist`?
> Do you have examples that rely on this?

From the core?  No, I cannot think of an example, but any user
configuration may make use of this feature.

I am not sure if I just missed it, but is there no technical solution
around the advice issue?  Couldn't `func-arity' check if the actual
function and the advice function have the same arity, and return the
right value in that case?  My impression is that in 99% of the cases,
advice isn't used to increase or decrease the arity of a function.

>
>         Stefan

Message #64 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Thu, 14 Sep 2023 09:47:07 -0400

>>> FWIW The intention here was to be able and specify simpler conditions
>>> that don't have to handle the alist.
>> You mean for `display-buffer-alist`?
>> Do you have examples that rely on this?
> From the core?  No, I cannot think of an example, but any user
> configuration may make use of this feature.

From the core would have been good, but from elsewhere (including
random .emacs config you may find on the web) would be helpful to gauge
how important that could be.

> I am not sure if I just missed it, but is there no technical solution
> around the advice issue?  Couldn't `func-arity' check if the actual
> function and the advice function have the same arity, and return the
> right value in that case?  My impression is that in 99% of the cases,
> advice isn't used to increase or decrease the arity of a function.

There are various 99% solutions, yes.
There is no 100% solution, OTOH :-(
So the documented behavior is inherently unreliable.


        Stefan

Message #67 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 15 Sep 2023 03:45:01 +0300

On 08/09/2023 20:01, Philip Kaludercic wrote:
> FWIW The intention here was to be able and specify simpler conditions
> that don't have to handle the alist.

There doesn't seem to be any built-in named functions that we expect to 
be used, so I suppose any such are either in custom files or third-party 
code (and are custom-written anyway). Then breaking those (asking the 
users to update them, basically) might not be the worst decision.

OTOH, the condition-case/wrong-number-of-arguments solution also should 
work 99,9% of the time, and that might cover all such functions in 
existence too.

Message #70 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 65797 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Thu, 14 Sep 2023 21:38:31 -0400

>> FWIW The intention here was to be able and specify simpler conditions
>> that don't have to handle the alist.
>
> There doesn't seem to be any built-in named functions that we expect to be
> used, so I suppose any such are either in custom files or third-party code
> (and are custom-written anyway). Then breaking those (asking the users to
> update them, basically) might not be the worst decision.
>
> OTOH, the condition-case/wrong-number-of-arguments solution also should work
> 99,9% of the time, and that might cover all such functions in existence too.

I'm not worried about breakage: we can keep the current `func-arity`
check (or replace it with a `condition-case`) to smooth over the change.

The main question is one of convenience: Philip wanted this DWIMish
behavior because he thought the added convenience was worth the
complexity (just without realizing that he was offering something we
can't really provide :-).

If the added convenience is not used in practice (or not significantly
enough to warrant the effort), then we can just change the
doc and move on.


        Stefan

Message #73 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 65797 <at> debbugs.gnu.org,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 15 Sep 2023 19:38:09 +0300

On 15/09/2023 04:38, Stefan Monnier wrote:
> The main question is one of convenience: Philip wanted this DWIMish
> behavior because he thought the added convenience was worth the
> complexity (just without realizing that he was offering something we
> can't really provide 😄.
> 
> If the added convenience is not used in practice (or not significantly
> enough to warrant the effort), then we can just change the
> doc and move on.

One of the considerations probably was to keep compatibility with the 
DSL in project-kill-buffer-conditions, where the predicate only receives 
one element.

I'm not sure if there are any actual predicates in use, though (the 
remander of the DSL seems to be very expressive on its own). But if 
there are we could say that the predicates are called with all the 
arguments that buffer-match-p is called with. And in this case it 
wouldn't be passed an extra arg, so the predicates would continue 
working as-is.

BTW, do we want to change '&optional ARG' to '&rest ARGS'? I don't have 
a use case in mind, but this would be the most flexible.

Message #76 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 15 Sep 2023 10:54:21 -0700

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> BTW, do we want to change '&optional ARG' to '&rest ARGS'? I don't
> have a use case in mind, but this would be the most flexible.

Like this?

https://yhetil.org/emacs-bugs/jwvv8cmdmzz.fsf-monnier+emacs <at> gnu.org/T/#mc073d249234777e6f04d809e7107c1893c7f6b2d

Message #79 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 15 Sep 2023 21:00:54 +0300

On 15/09/2023 20:54, Joseph Turner wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>> BTW, do we want to change '&optional ARG' to '&rest ARGS'? I don't
>> have a use case in mind, but this would be the most flexible.
> Like this?
> 
> https://yhetil.org/emacs-bugs/jwvv8cmdmzz.fsf-monnier+emacs <at> gnu.org/T/#mc073d249234777e6f04d809e7107c1893c7f6b2d

Pretty much. Sorry for the repetition.

Message #82 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 09:12:45 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> FWIW The intention here was to be able and specify simpler conditions
>>>> that don't have to handle the alist.
>>> You mean for `display-buffer-alist`?
>>> Do you have examples that rely on this?
>> From the core?  No, I cannot think of an example, but any user
>> configuration may make use of this feature.
>
> From the core would have been good, but from elsewhere (including
> random .emacs config you may find on the web) would be helpful to gauge
> how important that could be.

I don't know of any examples.

>> I am not sure if I just missed it, but is there no technical solution
>> around the advice issue?  Couldn't `func-arity' check if the actual
>> function and the advice function have the same arity, and return the
>> right value in that case?  My impression is that in 99% of the cases,
>> advice isn't used to increase or decrease the arity of a function.
>
> There are various 99% solutions, yes.
> There is no 100% solution, OTOH :-(
> So the documented behavior is inherently unreliable.

So what are the options then?  Does one have to pick a 99% solution?

-- 
Philip Kaludercic

Message #85 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 07:55:32 -0400

>>>>> FWIW The intention here was to be able and specify simpler conditions
>>>>> that don't have to handle the alist.
>>>> You mean for `display-buffer-alist`?
>>>> Do you have examples that rely on this?
>>> From the core?  No, I cannot think of an example, but any user
>>> configuration may make use of this feature.
>> From the core would have been good, but from elsewhere (including
>> random .emacs config you may find on the web) would be helpful to gauge
>> how important that could be.
> I don't know of any examples.

In that case I suggest we deprecate this feature (i.e. the fact that
the function can take a single arg).

>>> I am not sure if I just missed it, but is there no technical solution
>>> around the advice issue?  Couldn't `func-arity' check if the actual
>>> function and the advice function have the same arity, and return the
>>> right value in that case?  My impression is that in 99% of the cases,
>>> advice isn't used to increase or decrease the arity of a function.
>> There are various 99% solutions, yes.
>> There is no 100% solution, OTOH :-(
>> So the documented behavior is inherently unreliable.
> So what are the options then?

Alternatives I can see:

- Deprecate the feature with no replacement (i.e. users will have
  to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
  were using the feature).  That's my favorite option at this point.
- Replace it with some alternative (e.g. provide two different syntaxes
  for functions, one for functions that expect all args and one for
  functions that only take a single arg).
- Live with the occasional breakage and bug reports like the current one.

> Does one have to pick a 99% solution?

Hopefully not.  The 99% solution (whichever one is used) should
hopefully only be used temporarily for backward compatibility while the
feature is phased out.


        Stefan

Message #88 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 17:23:56 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>>>> FWIW The intention here was to be able and specify simpler conditions
>>>>>> that don't have to handle the alist.
>>>>> You mean for `display-buffer-alist`?
>>>>> Do you have examples that rely on this?
>>>> From the core?  No, I cannot think of an example, but any user
>>>> configuration may make use of this feature.
>>> From the core would have been good, but from elsewhere (including
>>> random .emacs config you may find on the web) would be helpful to gauge
>>> how important that could be.
>> I don't know of any examples.
>
> In that case I suggest we deprecate this feature (i.e. the fact that
> the function can take a single arg).
>
>>>> I am not sure if I just missed it, but is there no technical solution
>>>> around the advice issue?  Couldn't `func-arity' check if the actual
>>>> function and the advice function have the same arity, and return the
>>>> right value in that case?  My impression is that in 99% of the cases,
>>>> advice isn't used to increase or decrease the arity of a function.
>>> There are various 99% solutions, yes.
>>> There is no 100% solution, OTOH :-(
>>> So the documented behavior is inherently unreliable.
>> So what are the options then?
>
> Alternatives I can see:
>
> - Deprecate the feature with no replacement (i.e. users will have
>   to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
>   were using the feature).  That's my favorite option at this point.

I would be disappointed to see this path taken, since part of my hope
with buffer-match-p was that it could be used in project.el as well
(allowing this to be a thing is one of the reasons I started working on
Compat).

> - Replace it with some alternative (e.g. provide two different syntaxes
>   for functions, one for functions that expect all args and one for
>   functions that only take a single arg).

So `(arg1 ,(lambda (x) ...)) and `(arg2 ,(lambda (x y) ...))?  Or only
one, and otherwise we assume that the function can be invoked with a
single/two arguments?

> - Live with the occasional breakage and bug reports like the current one.

The issue here was related to advising a function.  And you are saying
there is no way around this, not even by annotating the function symbol
with the initial arity before it is advised.

>> Does one have to pick a 99% solution?
>
> Hopefully not.  The 99% solution (whichever one is used) should
> hopefully only be used temporarily for backward compatibility while the
> feature is phased out.
>
>
>         Stefan
>

-- 
Philip Kaludercic

Message #91 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 18 Sep 2023 14:05:48 -0400

>> - Deprecate the feature with no replacement (i.e. users will have
>>   to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
>>   were using the feature).  That's my favorite option at this point.
>
> I would be disappointed to see this path taken, since part of my hope
> with buffer-match-p was that it could be used in project.el as well
> (allowing this to be a thing is one of the reasons I started working on
> Compat).

I don't understand: you just told me you have no examples of places
where single-arg functions are concretely useful.

So, assuming `buffer-match-p` is used in many other things, like
`project.el`, do you have examples where the feature of choosing between
calling sometimes with one arg and sometimes with two would be
useful/handy?

[ BTW, changing the code to use `&rest args` instead of `&optional arg`
  would help for this, right?  ]

>> - Replace it with some alternative (e.g. provide two different syntaxes
>>   for functions, one for functions that expect all args and one for
>>   functions that only take a single arg).
>
> So `(arg1 ,(lambda (x) ...)) and `(arg2 ,(lambda (x y) ...))?

No, I was more thinking of `(pred1 FOO)` vs `(pred FOO)` or using just
`FOO` for those functions which take all the arguments and `[FOO]` for
those functions which only accept a single argument, or any other
suitable "annotation".
Or you could use an OClosure which carries some explicit user-provided
arity info with it.

>> - Live with the occasional breakage and bug reports like the current one.
> The issue here was related to advising a function.  And you are saying
> there is no way around this, not even by annotating the function symbol
> with the initial arity before it is advised.

No, we can fix this case with some ad-hoc hack.
But we can't fix every case once and for all, so the hack ends up being
very costly compared to its benefit.

The general rule is that you should never look at a function to decide
how to call it (more generally, you should never look at a function
beyond testing `functionp` or `commandp` (other than for debugging and
the like), you should only call it).


        Stefan

Message #94 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Tue, 19 Sep 2023 08:34:57 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> - Deprecate the feature with no replacement (i.e. users will have
>>>   to use a (lambda (x y) (foo x)) wrapper to drop the second arg if they
>>>   were using the feature).  That's my favorite option at this point.
>>
>> I would be disappointed to see this path taken, since part of my hope
>> with buffer-match-p was that it could be used in project.el as well
>> (allowing this to be a thing is one of the reasons I started working on
>> Compat).
>
> I don't understand: you just told me you have no examples of places
> where single-arg functions are concretely useful.

My apologies, to clarify: I don't know of any example where it is
currently used (project.el has a separate implementation), but this
would be one example where a single-argument invocation would be useful.

> So, assuming `buffer-match-p` is used in many other things, like
> `project.el`, do you have examples where the feature of choosing between
> calling sometimes with one arg and sometimes with two would be
> useful/handy?

That is a different matter.  Usually if buffer-match-p is not passed an
argument via ARG, then all the function calls would also just have a
single argument.  But in other examples, such as display-bufffer-alist
where ARG is non-nil, the user might want to fall back onto ignoring
ARG.  OTOH the difference between

  (lambda (buf) ...)

and

  (lambda (buf _) ...)

is not that great either.  So one could invoke the function with two
arguments if ARG is non-nil, and otherwise just with one.

> [ BTW, changing the code to use `&rest args` instead of `&optional arg`
>   would help for this, right?  ]

How come?

>>> - Replace it with some alternative (e.g. provide two different syntaxes
>>>   for functions, one for functions that expect all args and one for
>>>   functions that only take a single arg).
>>
>> So `(arg1 ,(lambda (x) ...)) and `(arg2 ,(lambda (x y) ...))?
>
> No, I was more thinking of `(pred1 FOO)` vs `(pred FOO)` or using just
> `FOO` for those functions which take all the arguments and `[FOO]` for
> those functions which only accept a single argument, or any other
> suitable "annotation".
> Or you could use an OClosure which carries some explicit user-provided
> arity info with it.

How would that look like?

>>> - Live with the occasional breakage and bug reports like the current one.
>> The issue here was related to advising a function.  And you are saying
>> there is no way around this, not even by annotating the function symbol
>> with the initial arity before it is advised.
>
> No, we can fix this case with some ad-hoc hack.
> But we can't fix every case once and for all, so the hack ends up being
> very costly compared to its benefit.
>
> The general rule is that you should never look at a function to decide
> how to call it (more generally, you should never look at a function
> beyond testing `functionp` or `commandp` (other than for debugging and
> the like), you should only call it).

OK, I see, I was not familiar with this principle.

>
>         Stefan

Message #97 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Philip Kaludercic <philipk <at> posteo.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Tue, 19 Sep 2023 13:06:41 +0300

On 19/09/2023 11:34, Philip Kaludercic wrote:
>> [ BTW, changing the code to use `&rest args` instead of `&optional arg`
>>    would help for this, right?  ]
> How come?

In project.el buffer-match-p would be called without an extra argument, 
so the predicates would be called without an extra argument as well.

That should take care of that compatibility, I think.

Message #100 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Joseph Turner <joseph <at> breatheoutbreathe.in>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Tue, 19 Sep 2023 13:56:54 +0000

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 19/09/2023 11:34, Philip Kaludercic wrote:
>>> [ BTW, changing the code to use `&rest args` instead of `&optional arg`
>>>    would help for this, right?  ]
>> How come?
>
> In project.el buffer-match-p would be called without an extra
> argument, so the predicates would be called without an extra argument
> as well.
>
> That should take care of that compatibility, I think.

But what does that have to do with &rest vs &optional?

Message #103 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Joseph Turner <joseph <at> breatheoutbreathe.in>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Tue, 19 Sep 2023 19:13:40 +0300

On 19/09/2023 16:56, Philip Kaludercic wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>> On 19/09/2023 11:34, Philip Kaludercic wrote:
>>>> [ BTW, changing the code to use `&rest args` instead of `&optional arg`
>>>>     would help for this, right?  ]
>>> How come?
>> In project.el buffer-match-p would be called without an extra
>> argument, so the predicates would be called without an extra argument
>> as well.
>>
>> That should take care of that compatibility, I think.
> But what does that have to do with &rest vs &optional?

Stringly speaking, nothing, because you can manage the same scheme with 
&optional - just dispatching to pred with different number of arguments 
depending on whether the &optional arg is nil. Though that breaks a 
little when nil is a meaningful value (probably a rare case).

Rewriting the function in terms of &rest just makes this solution the 
most natural one, I suppose.

Though we'll still have to document the distinction in the docstrings of 
project-kill-buffer-conditions and etc (the number of the arguments 
called with).

Message #106 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 65797 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sun, 08 Oct 2023 02:10:33 -0700

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 19/09/2023 16:56, Philip Kaludercic wrote:
>> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
>>
>>> On 19/09/2023 11:34, Philip Kaludercic wrote:
>>>>> [ BTW, changing the code to use `&rest args` instead of `&optional arg`
>>>>>     would help for this, right?  ]
>>>> How come?
>>> In project.el buffer-match-p would be called without an extra
>>> argument, so the predicates would be called without an extra argument
>>> as well.
>>>
>>> That should take care of that compatibility, I think.
>> But what does that have to do with &rest vs &optional?
>
> Stringly speaking, nothing, because you can manage the same scheme
> with &optional - just dispatching to pred with different number of
> arguments depending on whether the &optional arg is nil. Though that
> breaks a little when nil is a meaningful value (probably a rare case).
>
> Rewriting the function in terms of &rest just makes this solution the
> most natural one, I suppose.

I am in favor of this solution as well.

> Though we'll still have to document the distinction in the docstrings
> of project-kill-buffer-conditions and etc (the number of the arguments
> called with).

How do the project.el docstrings need to be updated?

Thank you!

Joseph

Message #109 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 65797 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sun, 8 Oct 2023 13:25:49 +0300

On 08/10/2023 12:10, Joseph Turner wrote:
>> Though we'll still have to document the distinction in the docstrings
>> of project-kill-buffer-conditions and etc (the number of the arguments
>> called with).
> How do the project.el docstrings need to be updated?

Bad phrasing on my part, sorry: no need to touch them in this particular 
patch. Or probably after (the number of args will stay unchanged).

But other similar variables, especially new ones, related to the user of 
buffer-match-p, would need to mention the number of args passed to PRED.

Message #112 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 09 Oct 2023 17:40:57 -0400

> I am in favor of this solution as well.

Then how 'bout something like the patch below which changes the
`&optional` into an `&rest` but tries to preserve compatibility with the
old calling convention.


        Stefan


diff --git a/lisp/subr.el b/lisp/subr.el
index e88815fa58c..06c9923b525 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7295,13 +7292,13 @@ string-lines
             (setq start (length string)))))
       (nreverse lines))))
 
-(defun buffer-match-p (condition buffer-or-name &optional arg)
+(defun buffer-match-p (condition buffer-or-name &rest args)
   "Return non-nil if BUFFER-OR-NAME matches CONDITION.
 CONDITION is either:
 - the symbol t, to always match,
 - the symbol nil, which never matches,
 - a regular expression, to match a buffer name,
-- a predicate function that takes BUFFER-OR-NAME and ARG as
+- a predicate function that takes BUFFER-OR-NAME plus ARGS as
   arguments, and returns non-nil if the buffer matches,
 - a cons-cell, where the car describes how to interpret the cdr.
   The car can be one of the following:
@@ -7326,9 +7323,18 @@ buffer-match-p
                       ((pred stringp)
                        (string-match-p condition (buffer-name buffer)))
                       ((pred functionp)
-                       (if (eq 1 (cdr (func-arity condition)))
-                           (funcall condition buffer-or-name)
-                         (funcall condition buffer-or-name arg)))
+                       (if (cdr args)
+                           ;; More than 1 argument: no need for
+                           ;; Emacs-29 backward compatibility!
+                           (apply condition buffer-or-name args)
+                         (condition-case err
+                             (apply condition buffer-or-name args)
+                           (wrong-number-of-arguments
+                            ;; Backward compatibility with Emacs-29 semantics.
+                            (message "Trying obsolete calling convention for: %S"
+                                     condition)
+                            (apply condition buffer-or-name
+                                   (if args '(nil) nil))))))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)
@@ -7350,17 +7356,17 @@ buffer-match-p
                 (throw 'match t)))))))
     (funcall match (list condition))))
 
-(defun match-buffers (condition &optional buffers arg)
+(defun match-buffers (condition &optional buffers &rest args)
   "Return a list of buffers that match CONDITION, or nil if none match.
 See `buffer-match-p' for various supported CONDITIONs.
 By default all buffers are checked, but the optional
 argument BUFFERS can restrict that: its value should be
 an explicit list of buffers to check.
-Optional argument ARG is passed to `buffer-match-p', for
+Optional arguments ARGS are passed to `buffer-match-p', for
 predicate conditions in CONDITION."
   (let (bufs)
     (dolist (buf (or buffers (buffer-list)))
-      (when (buffer-match-p condition (get-buffer buf) arg)
+      (when (apply #'buffer-match-p condition (get-buffer buf) args)
         (push buf bufs)))
     bufs))
 

Message #115 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Wed, 11 Oct 2023 21:53:31 -0700

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I am in favor of this solution as well.
>
> Then how 'bout something like the patch below which changes the
> `&optional` into an `&rest` but tries to preserve compatibility with the
> old calling convention.
>
>
>         Stefan
>
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index e88815fa58c..06c9923b525 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7295,13 +7292,13 @@ string-lines
>              (setq start (length string)))))
>        (nreverse lines))))
>
> -(defun buffer-match-p (condition buffer-or-name &optional arg)
> +(defun buffer-match-p (condition buffer-or-name &rest args)
>    "Return non-nil if BUFFER-OR-NAME matches CONDITION.
>  CONDITION is either:
>  - the symbol t, to always match,
>  - the symbol nil, which never matches,
>  - a regular expression, to match a buffer name,
> -- a predicate function that takes BUFFER-OR-NAME and ARG as
> +- a predicate function that takes BUFFER-OR-NAME plus ARGS as
>    arguments, and returns non-nil if the buffer matches,
>  - a cons-cell, where the car describes how to interpret the cdr.
>    The car can be one of the following:
> @@ -7326,9 +7323,18 @@ buffer-match-p
>                        ((pred stringp)
>                         (string-match-p condition (buffer-name buffer)))
>                        ((pred functionp)
> -                       (if (eq 1 (cdr (func-arity condition)))
> -                           (funcall condition buffer-or-name)
> -                         (funcall condition buffer-or-name arg)))
> +                       (if (cdr args)
> +                           ;; More than 1 argument: no need for
> +                           ;; Emacs-29 backward compatibility!
> +                           (apply condition buffer-or-name args)
> +                         (condition-case err
> +                             (apply condition buffer-or-name args)
> +                           (wrong-number-of-arguments
> +                            ;; Backward compatibility with Emacs-29 semantics.
> +                            (message "Trying obsolete calling convention for: %S"
> +                                     Condition)
> +                            (apply condition buffer-or-name
> +                                   (if args '(nil) nil))))))
>                        (`(major-mode . ,mode)
>                         (eq
>                          (buffer-local-value 'major-mode buffer)
> @@ -7350,17 +7356,17 @@ buffer-match-p
>                  (throw 'match t)))))))
>      (funcall match (list condition))))

At first, I was concerned that the condition-case would mess up error
handling in user code, but all 9 permutations give the expected results:

(let ((condition
       (lambda (buf) t)
       ;; (lambda (buf arg1) t)
       ;; (lambda (buf arg1 arg2) t)
       ))
  (condition-case err
      (buffer-match-p condition (current-buffer)
                      ;; 'arg1
                      ;; 'arg2
                      )
    (wrong-number-of-arguments
     "Caught")))

> -(defun match-buffers (condition &optional buffers arg)
> +(defun match-buffers (condition &optional buffers &rest args)
>    "Return a list of buffers that match CONDITION, or nil if none match.
>  See `buffer-match-p' for various supported CONDITIONs.
>  By default all buffers are checked, but the optional
>  argument BUFFERS can restrict that: its value should be
>  an explicit list of buffers to check.
> -Optional argument ARG is passed to `buffer-match-p', for
> +Optional arguments ARGS are passed to `buffer-match-p', for
>  predicate conditions in CONDITION."
>    (let (bufs)
>      (dolist (buf (or buffers (buffer-list)))
> -      (when (buffer-match-p condition (get-buffer buf) arg)
> +      (when (apply #'buffer-match-p condition (get-buffer buf) args)
>          (push buf bufs)))
>      bufs))
>

Message #118 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Thu, 12 Oct 2023 14:34:13 +0300

On 10/10/2023 00:40, Stefan Monnier wrote:
> Then how 'bout something like the patch below which changes the
> `&optional` into an `&rest` but tries to preserve compatibility with the
> old calling convention.

Personally, I figured that using &rest would already help with backward 
compatibility to an extent.

Message #121 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 65797 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 Joseph Turner <joseph <at> breatheoutbreathe.in>
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 13 Oct 2023 11:57:59 -0400

>> Then how 'bout something like the patch below which changes the
>> `&optional` into an `&rest` but tries to preserve compatibility with the
>> old calling convention.
> Personally, I figured that using &rest would already help with backward
> compatibility to an extent.

I don't have a good intuition for how important backward compatibility
is here, so I went for the "safe" choice.  But maybe we don't need to go
that far.  The patch below keeps the same compatibility hack as we
currently have but doesn't add any new compatibility, so it will break
those uses where `buffer-match-p` is called without additional args but
the predicate function still expects 2 args (where the second is always
nil).  Indeed, that case seemes extremely unlikely.

Eli, Stefan, WDYT?


        Stefan


diff --git a/lisp/subr.el b/lisp/subr.el
index e88815fa58c..b38a29058a4 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7295,13 +7295,13 @@ string-lines
             (setq start (length string)))))
       (nreverse lines))))
 
-(defun buffer-match-p (condition buffer-or-name &optional arg)
+(defun buffer-match-p (condition buffer-or-name &rest args)
   "Return non-nil if BUFFER-OR-NAME matches CONDITION.
 CONDITION is either:
 - the symbol t, to always match,
 - the symbol nil, which never matches,
 - a regular expression, to match a buffer name,
-- a predicate function that takes BUFFER-OR-NAME and ARG as
+- a predicate function that takes BUFFER-OR-NAME plus ARGS as
   arguments, and returns non-nil if the buffer matches,
 - a cons-cell, where the car describes how to interpret the cdr.
   The car can be one of the following:
@@ -7326,9 +7326,14 @@ buffer-match-p
                       ((pred stringp)
                        (string-match-p condition (buffer-name buffer)))
                       ((pred functionp)
-                       (if (eq 1 (cdr (func-arity condition)))
-                           (funcall condition buffer-or-name)
-                         (funcall condition buffer-or-name arg)))
+                       (apply condition buffer-or-name
+                              (cond
+                               ;; Backward compatibility with
+                               ;;  Emacs-29 semantics.
+                               ((and args (null (cdr args))
+                                     (eq 1 (cdr (func-arity condition))))
+                                nil)
+                               (t args))))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)
@@ -7350,17 +7355,17 @@ buffer-match-p
                 (throw 'match t)))))))
     (funcall match (list condition))))
 
-(defun match-buffers (condition &optional buffers arg)
+(defun match-buffers (condition &optional buffers &rest args)
   "Return a list of buffers that match CONDITION, or nil if none match.
 See `buffer-match-p' for various supported CONDITIONs.
 By default all buffers are checked, but the optional
 argument BUFFERS can restrict that: its value should be
 an explicit list of buffers to check.
-Optional argument ARG is passed to `buffer-match-p', for
+Optional arguments ARGS are passed to `buffer-match-p', for
 predicate conditions in CONDITION."
   (let (bufs)
     (dolist (buf (or buffers (buffer-list)))
-      (when (buffer-match-p condition (get-buffer buf) arg)
+      (when (apply #'buffer-match-p condition (get-buffer buf) args)
         (push buf bufs)))
     bufs))
 

Message #124 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sat, 14 Oct 2023 09:13:19 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Joseph Turner <joseph <at> breatheoutbreathe.in>,  Philip Kaludercic
>  <philipk <at> posteo.net>,  Mattias Engdegård
>  <mattias.engdegard <at> gmail.com>,
>   Eli Zaretskii <eliz <at> gnu.org>,  65797 <at> debbugs.gnu.org
> Date: Fri, 13 Oct 2023 11:57:59 -0400
> 
> >> Then how 'bout something like the patch below which changes the
> >> `&optional` into an `&rest` but tries to preserve compatibility with the
> >> old calling convention.
> > Personally, I figured that using &rest would already help with backward
> > compatibility to an extent.
> 
> I don't have a good intuition for how important backward compatibility
> is here, so I went for the "safe" choice.  But maybe we don't need to go
> that far.  The patch below keeps the same compatibility hack as we
> currently have but doesn't add any new compatibility, so it will break
> those uses where `buffer-match-p` is called without additional args but
> the predicate function still expects 2 args (where the second is always
> nil).  Indeed, that case seemes extremely unlikely.
> 
> Eli, Stefan, WDYT?

TBH, I have no way of assessing the risks in such a change.

Do we have to make this change on the release branch?  What bad things
will happen if we leave emacs-29 with no changes?  The discussion
thread is quite long, but my personal take from it is that the
arguments for making any changes in the current code are largely
theoretical and aesthetic.  Am I wrong?

Message #127 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sat, 14 Oct 2023 10:31:29 -0400

> TBH, I have no way of assessing the risks in such a change.

Same here, which is why my first patch tried to play it safe.

> Do we have to make this change on the release branch?

That's another question, indeed.

> What bad things will happen if we leave emacs-29 with no changes?

Nothing too serious.
`buffer-match-p` is new in Emacs-29 and it is documented (in the Texinfo,
not in the docstring) to provide a behavior we're unable to implement.
So the main aim of the patch is to "fix" this new API so it can be
implemented as documented.

But the problem is somewhat corner-case, so it's not super urgent to fix it.

OTOH, the change is minor and fairly safe.
Basically the patch replaces an &optional with a &rest in the API.
Besides allowing more cases (which is mostly a non-issue in terms of
backward compatibility), this introduces just 1 potential problem:

When `buffer-match-p` is called without the formerly optional arg, it
will call the predicate functions with one fewer arg than before.

The Emacs-29.1 code has a hack that tries to detect when the predicate
expects "one fewer arg" and if so calls it without the optional arg, so
I just extended that hack to also handle that reverse problem (when
there is one fewer arg than expected by the function).

If we put it into `master`, I guess we can stick to the original hack
and hope the above "just 1 potential problem" won't bite us, but it
seems we may as well use the more backward compliant option and put it
into `emacs-29`.

See below my current "safe" choice.


        Stefan


diff --git a/lisp/subr.el b/lisp/subr.el
index 58274987d71..89bf8b44be7 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7277,13 +7275,13 @@ string-lines
             (setq start (length string)))))
       (nreverse lines))))
 
-(defun buffer-match-p (condition buffer-or-name &optional arg)
+(defun buffer-match-p (condition buffer-or-name &rest args)
   "Return non-nil if BUFFER-OR-NAME matches CONDITION.
 CONDITION is either:
 - the symbol t, to always match,
 - the symbol nil, which never matches,
 - a regular expression, to match a buffer name,
-- a predicate function that takes BUFFER-OR-NAME and ARG as
+- a predicate function that takes BUFFER-OR-NAME plus ARGS as
   arguments, and returns non-nil if the buffer matches,
 - a cons-cell, where the car describes how to interpret the cdr.
   The car can be one of the following:
@@ -7308,9 +7306,16 @@ buffer-match-p
                       ((pred stringp)
                        (string-match-p condition (buffer-name buffer)))
                       ((pred functionp)
-                       (if (eq 1 (cdr (func-arity condition)))
-                           (funcall condition buffer-or-name)
-                         (funcall condition buffer-or-name arg)))
+                       (let ((max (cdr (func-arity condition))))
+                         (if (if args
+                                 ;; Old compatibility code present
+                                 ;; and documented in Emacs-29.1.
+                                 (and (null (cdr args)) (eq 1 max))
+                               ;; Backward compatibility with Emacs-29.1.
+                               (or (eq max 'many) (> max 1)))
+                             (apply condition buffer-or-name
+                                    (if args '(nil) nil))
+                           (apply condition buffer-or-name args))))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)
@@ -7332,17 +7337,17 @@ buffer-match-p
                 (throw 'match t)))))))
     (funcall match (list condition))))
 
-(defun match-buffers (condition &optional buffers arg)
+(defun match-buffers (condition &optional buffers &rest args)
   "Return a list of buffers that match CONDITION, or nil if none match.
 See `buffer-match-p' for various supported CONDITIONs.
 By default all buffers are checked, but the optional
 argument BUFFERS can restrict that: its value should be
 an explicit list of buffers to check.
-Optional argument ARG is passed to `buffer-match-p', for
+Optional arguments ARGS are passed to `buffer-match-p', for
 predicate conditions in CONDITION."
   (let (bufs)
     (dolist (buf (or buffers (buffer-list)))
-      (when (buffer-match-p condition (get-buffer buf) arg)
+      (when (apply #'buffer-match-p condition (get-buffer buf) args)
         (push buf bufs)))
     bufs))
 

Message #130 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Sun, 15 Oct 2023 09:13:27 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dmitry <at> gutov.dev,  joseph <at> breatheoutbreathe.in,  philipk <at> posteo.net,
>   mattias.engdegard <at> gmail.com,  65797 <at> debbugs.gnu.org
> Date: Sat, 14 Oct 2023 10:31:29 -0400
> 
> > What bad things will happen if we leave emacs-29 with no changes?
> 
> Nothing too serious.
> `buffer-match-p` is new in Emacs-29 and it is documented (in the Texinfo,
> not in the docstring) to provide a behavior we're unable to implement.
> So the main aim of the patch is to "fix" this new API so it can be
> implemented as documented.
> 
> But the problem is somewhat corner-case, so it's not super urgent to fix it.
> 
> OTOH, the change is minor and fairly safe.
> Basically the patch replaces an &optional with a &rest in the API.
> Besides allowing more cases (which is mostly a non-issue in terms of
> backward compatibility), this introduces just 1 potential problem:
> 
> When `buffer-match-p` is called without the formerly optional arg, it
> will call the predicate functions with one fewer arg than before.
> 
> The Emacs-29.1 code has a hack that tries to detect when the predicate
> expects "one fewer arg" and if so calls it without the optional arg, so
> I just extended that hack to also handle that reverse problem (when
> there is one fewer arg than expected by the function).
> 
> If we put it into `master`, I guess we can stick to the original hack
> and hope the above "just 1 potential problem" won't bite us, but it
> seems we may as well use the more backward compliant option and put it
> into `emacs-29`.
> 
> See below my current "safe" choice.

Sigh.  I guess we can install this on emacs-29 and cross the
fingers...

Message #133 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 16 Oct 2023 12:33:10 -0400

[Message part 1 (text/plain, inline)]

> Sigh.  I guess we can install this on emacs-29 and cross the
> fingers...

I'm not insisting on it.
If you think it's risky, let's just have it on `master`.

BTW, see below the actual patch, including changes to etc/NEWS, manual,
as well as the addition of a runtime warning (without which I can't see
how we'll ever be able to get rid of the ugly backward compatibility
hack).


        Stefan

[buffer-match.patch (text/x-diff, inline)]

diff --git a/doc/lispref/buffers.texi b/doc/lispref/buffers.texi
index 86c47ae7310..a2d0f5687ba 100644
--- a/doc/lispref/buffers.texi
+++ b/doc/lispref/buffers.texi
@@ -957,10 +957,10 @@ Buffer List
 infinite recursion.
 @end defvar
 
-@defun buffer-match-p condition buffer-or-name &optional arg
+@defun buffer-match-p condition buffer-or-name &rest args
 This function checks if a buffer designated by @code{buffer-or-name}
-satisfies the specified @code{condition}.  Optional third argument
-@var{arg} is passed to the predicate function in @var{condition}.  A
+satisfies the specified @code{condition}.  Optional arguments
+@var{args} are passed to the predicate function in @var{condition}.  A
 valid @var{condition} can be one of the following:
 @itemize @bullet{}
 @item
@@ -969,23 +969,21 @@ Buffer List
 name.
 @item
 A predicate function, which should return non-@code{nil} if the buffer
-matches.  If the function expects one argument, it is called with
-@var{buffer-or-name} as the argument; if it expects 2 arguments, the
-first argument is @var{buffer-or-name} and the second is @var{arg}
-(or @code{nil} if @var{arg} is omitted).
+matches.  It is called with
+@var{buffer-or-name} as the first argument followed by @var{args}.
 @item
 A cons-cell @code{(@var{oper} . @var{expr})} where @var{oper} is one
 of
 @table @code
 @item (not @var{cond})
 Satisfied if @var{cond} doesn't satisfy @code{buffer-match-p} with
-the same buffer and @code{arg}.
+the same buffer and @code{args}.
 @item (or @var{conds}@dots{})
 Satisfied if @emph{any} condition in @var{conds} satisfies
-@code{buffer-match-p}, with the same buffer and @code{arg}.
+@code{buffer-match-p}, with the same buffer and @code{args}.
 @item (and @var{conds}@dots{})
 Satisfied if @emph{all} the conditions in @var{conds} satisfy
-@code{buffer-match-p}, with the same buffer and @code{arg}.
+@code{buffer-match-p}, with the same buffer and @code{args}.
 @item derived-mode
 Satisfied if the buffer's major mode derives from @var{expr}.
 @item major-mode
@@ -998,14 +996,14 @@ Buffer List
 @end itemize
 @end defun
 
-@defun match-buffers condition &optional buffer-list arg
+@defun match-buffers condition &optional buffer-list &rest args
 This function returns a list of all buffers that satisfy the
 @code{condition}.  If no buffers match, the function returns
 @code{nil}.  The argument @var{condition} is as defined in
 @code{buffer-match-p} above.  By default, all the buffers are
 considered, but this can be restricted via the optional argument
 @code{buffer-list}, which should be a list of buffers to consider.
-Optional third argument @var{arg} will be passed to @var{condition} in
+Remaining arguments @var{args} will be passed to @var{condition} in
 the same way as @code{buffer-match-p} does.
 @end defun
 
diff --git a/etc/NEWS b/etc/NEWS
index 3bd47a0112b..c74b4978afe 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -945,6 +945,13 @@ the file listing's performance is still optimized.
 
 * Incompatible Lisp Changes in Emacs 30.1
 
+** `buffer-match-p and `match-buffers` take `&rest args`
+They used to take a single `&optional arg` and were documented to use
+an unreliable hack to try and accommodate condition predicates that
+don't accept this optional arg.
+The new semantics makes no such affordances, tho the code still
+supports it (with a warning) for backward compatibility.
+
 ** 'post-gc-hook' runs after updating 'gcs-done' and 'gcs-elapsed'.
 
 ---
diff --git a/lisp/subr.el b/lisp/subr.el
index 58274987d71..0732319ccd0 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7277,13 +7277,15 @@ string-lines
             (setq start (length string)))))
       (nreverse lines))))
 
-(defun buffer-match-p (condition buffer-or-name &optional arg)
+(defvar buffer-match-p--past-warnings nil)
+
+(defun buffer-match-p (condition buffer-or-name &rest args)
   "Return non-nil if BUFFER-OR-NAME matches CONDITION.
 CONDITION is either:
 - the symbol t, to always match,
 - the symbol nil, which never matches,
 - a regular expression, to match a buffer name,
-- a predicate function that takes BUFFER-OR-NAME and ARG as
+- a predicate function that takes BUFFER-OR-NAME plus ARGS as
   arguments, and returns non-nil if the buffer matches,
 - a cons-cell, where the car describes how to interpret the cdr.
   The car can be one of the following:
@@ -7308,9 +7310,18 @@ buffer-match-p
                       ((pred stringp)
                        (string-match-p condition (buffer-name buffer)))
                       ((pred functionp)
-                       (if (eq 1 (cdr (func-arity condition)))
-                           (funcall condition buffer-or-name)
-                         (funcall condition buffer-or-name arg)))
+                       (if (cdr args)
+                           ;; New in Emacs>29.1. no need for compatibility hack.
+                           (apply condition buffer-or-name args)
+                         (condition-case-unless-debug err
+                             (apply condition buffer-or-name args)
+                           (wrong-number-of-arguments
+                            (unless (member condition
+                                            buffer-match-p--past-warnings)
+                              (message "%s" (error-message-string err))
+                              (push condition buffer-match-p--past-warnings))
+                            (apply condition buffer-or-name
+                                   (if args nil '(nil)))))))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)
@@ -7332,17 +7343,17 @@ buffer-match-p
                 (throw 'match t)))))))
     (funcall match (list condition))))
 
-(defun match-buffers (condition &optional buffers arg)
+(defun match-buffers (condition &optional buffers &rest args)
   "Return a list of buffers that match CONDITION, or nil if none match.
 See `buffer-match-p' for various supported CONDITIONs.
 By default all buffers are checked, but the optional
 argument BUFFERS can restrict that: its value should be
 an explicit list of buffers to check.
-Optional argument ARG is passed to `buffer-match-p', for
+Optional arguments ARGS are passed to `buffer-match-p', for
 predicate conditions in CONDITION."
   (let (bufs)
     (dolist (buf (or buffers (buffer-list)))
-      (when (buffer-match-p condition (get-buffer buf) arg)
+      (when (apply #'buffer-match-p condition (get-buffer buf) args)
         (push buf bufs)))
     bufs))
 
diff --git a/lisp/window.el b/lisp/window.el
index 2f9b46ebb0a..12d3fb1dfe7 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7535,10 +7535,8 @@ display-buffer-alist
   arguments: a buffer to display and an alist of the same form as
   ALIST.  See `display-buffer' for details.
 
-`display-buffer' scans this alist until it either finds a
-matching regular expression or the function specified by a
-condition returns non-nil.  In any of these cases, it adds the
-associated action to the list of actions it will try."
+`display-buffer' scans this alist until the CONDITION is satisfied
+and adds the associated ACTION to the list of actions it will try."
   :type `(alist :key-type
 		(choice :tag "Condition"
 			regexp

Message #136 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: dmitry <at> gutov.dev, Eli Zaretskii <eliz <at> gnu.org>, mattias.engdegard <at> gmail.com,
 philipk <at> posteo.net, 65797 <at> debbugs.gnu.org
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Mon, 16 Oct 2023 13:16:32 -0700

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Sigh.  I guess we can install this on emacs-29 and cross the
>> fingers...
>
> I'm not insisting on it.
> If you think it's risky, let's just have it on `master`.
>
> BTW, see below the actual patch, including changes to etc/NEWS, manual,
> as well as the addition of a runtime warning (without which I can't see
> how we'll ever be able to get rid of the ugly backward compatibility
> hack).

Minor nit: There's a typo in the NEWS file. "tho" should be "though".

>         Stefan
>
> [2. text/x-diff; buffer-match.patch]
> diff --git a/doc/lispref/buffers.texi b/doc/lispref/buffers.texi
> index 86c47ae7310..a2d0f5687ba 100644
> --- a/doc/lispref/buffers.texi
> +++ b/doc/lispref/buffers.texi
> @@ -957,10 +957,10 @@ Buffer List
>  infinite recursion.
>  @end defvar
>
> -@defun buffer-match-p condition buffer-or-name &optional arg
> +@defun buffer-match-p condition buffer-or-name &rest args
>  This function checks if a buffer designated by @code{buffer-or-name}
> -satisfies the specified @code{condition}.  Optional third argument
> -@var{arg} is passed to the predicate function in @var{condition}.  A
> +satisfies the specified @code{condition}.  Optional arguments
> +@var{args} are passed to the predicate function in @var{condition}.  A
>  valid @var{condition} can be one of the following:
>  @itemize @bullet{}
>  @item
> @@ -969,23 +969,21 @@ Buffer List
>  name.
>  @item
>  A predicate function, which should return non-@code{nil} if the buffer
> -matches.  If the function expects one argument, it is called with
> -@var{buffer-or-name} as the argument; if it expects 2 arguments, the
> -first argument is @var{buffer-or-name} and the second is @var{arg}
> -(or @code{nil} if @var{arg} is omitted).
> +matches.  It is called with
> +@var{buffer-or-name} as the first argument followed by @var{args}.
>  @item
>  A cons-cell @code{(@var{oper} . @var{expr})} where @var{oper} is one
>  of
>  @table @code
>  @item (not @var{cond})
>  Satisfied if @var{cond} doesn't satisfy @code{buffer-match-p} with
> -the same buffer and @code{arg}.
> +the same buffer and @code{args}.
>  @item (or @var{conds}@dots{})
>  Satisfied if @emph{any} condition in @var{conds} satisfies
> -@code{buffer-match-p}, with the same buffer and @code{arg}.
> +@code{buffer-match-p}, with the same buffer and @code{args}.
>  @item (and @var{conds}@dots{})
>  Satisfied if @emph{all} the conditions in @var{conds} satisfy
> -@code{buffer-match-p}, with the same buffer and @code{arg}.
> +@code{buffer-match-p}, with the same buffer and @code{args}.
>  @item derived-mode
>  Satisfied if the buffer's major mode derives from @var{expr}.
>  @item major-mode
> @@ -998,14 +996,14 @@ Buffer List
>  @end itemize
>  @end defun
>
> -@defun match-buffers condition &optional buffer-list arg
> +@defun match-buffers condition &optional buffer-list &rest args
>  This function returns a list of all buffers that satisfy the
>  @code{condition}.  If no buffers match, the function returns
>  @code{nil}.  The argument @var{condition} is as defined in
>  @code{buffer-match-p} above.  By default, all the buffers are
>  considered, but this can be restricted via the optional argument
>  @code{buffer-list}, which should be a list of buffers to consider.
> -Optional third argument @var{arg} will be passed to @var{condition} in
> +Remaining arguments @var{args} will be passed to @var{condition} in
>  the same way as @code{buffer-match-p} does.
>  @end defun
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 3bd47a0112b..c74b4978afe 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -945,6 +945,13 @@ the file listing's performance is still optimized.
>  
>  * Incompatible Lisp Changes in Emacs 30.1
>
> +** `buffer-match-p and `match-buffers` take `&rest args`
> +They used to take a single `&optional arg` and were documented to use
> +an unreliable hack to try and accommodate condition predicates that
> +don't accept this optional arg.
> +The new semantics makes no such affordances, tho the code still
> +supports it (with a warning) for backward compatibility.
> +
>  ** 'post-gc-hook' runs after updating 'gcs-done' and 'gcs-elapsed'.
>
>  ---
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 58274987d71..0732319ccd0 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7277,13 +7277,15 @@ string-lines
>              (setq start (length string)))))
>        (nreverse lines))))
>
> -(defun buffer-match-p (condition buffer-or-name &optional arg)
> +(defvar buffer-match-p--past-warnings nil)
> +
> +(defun buffer-match-p (condition buffer-or-name &rest args)
>    "Return non-nil if BUFFER-OR-NAME matches CONDITION.
>  CONDITION is either:
>  - the symbol t, to always match,
>  - the symbol nil, which never matches,
>  - a regular expression, to match a buffer name,
> -- a predicate function that takes BUFFER-OR-NAME and ARG as
> +- a predicate function that takes BUFFER-OR-NAME plus ARGS as
>    arguments, and returns non-nil if the buffer matches,
>  - a cons-cell, where the car describes how to interpret the cdr.
>    The car can be one of the following:
> @@ -7308,9 +7310,18 @@ buffer-match-p
>                        ((pred stringp)
>                         (string-match-p condition (buffer-name buffer)))
>                        ((pred functionp)
> -                       (if (eq 1 (cdr (func-arity condition)))
> -                           (funcall condition buffer-or-name)
> -                         (funcall condition buffer-or-name arg)))
> +                       (if (cdr args)
> +                           ;; New in Emacs>29.1. no need for compatibility hack.
> +                           (apply condition buffer-or-name args)
> +                         (condition-case-unless-debug err
> +                             (apply condition buffer-or-name args)
> +                           (wrong-number-of-arguments
> +                            (unless (member condition
> +                                            buffer-match-p--past-warnings)
> +                              (message "%s" (error-message-string err))
> +                              (push condition buffer-match-p--past-warnings))
> +                            (apply condition buffer-or-name
> +                                   (if args nil '(nil)))))))
>                        (`(major-mode . ,mode)
>                         (eq
>                          (buffer-local-value 'major-mode buffer)
> @@ -7332,17 +7343,17 @@ buffer-match-p
>                  (throw 'match t)))))))
>      (funcall match (list condition))))
>
> -(defun match-buffers (condition &optional buffers arg)
> +(defun match-buffers (condition &optional buffers &rest args)
>    "Return a list of buffers that match CONDITION, or nil if none match.
>  See `buffer-match-p' for various supported CONDITIONs.
>  By default all buffers are checked, but the optional
>  argument BUFFERS can restrict that: its value should be
>  an explicit list of buffers to check.
> -Optional argument ARG is passed to `buffer-match-p', for
> +Optional arguments ARGS are passed to `buffer-match-p', for
>  predicate conditions in CONDITION."
>    (let (bufs)
>      (dolist (buf (or buffers (buffer-list)))
> -      (when (buffer-match-p condition (get-buffer buf) arg)
> +      (when (apply #'buffer-match-p condition (get-buffer buf) args)
>          (push buf bufs)))
>      bufs))
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 2f9b46ebb0a..12d3fb1dfe7 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -7535,10 +7535,8 @@ display-buffer-alist
>    arguments: a buffer to display and an alist of the same form as
>    ALIST.  See `display-buffer' for details.
>
> -`display-buffer' scans this alist until it either finds a
> -matching regular expression or the function specified by a
> -condition returns non-nil.  In any of these cases, it adds the
> -associated action to the list of actions it will try."
> +`display-buffer' scans this alist until the CONDITION is satisfied
> +and adds the associated ACTION to the list of actions it will try."
>    :type `(alist :key-type
>  		(choice :tag "Condition"
>  			regexp

Message #139 received at 65797 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 65797 <at> debbugs.gnu.org, dmitry <at> gutov.dev, philipk <at> posteo.net,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Thu, 19 Oct 2023 15:18:12 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: dmitry <at> gutov.dev,  joseph <at> breatheoutbreathe.in,  philipk <at> posteo.net,
>   mattias.engdegard <at> gmail.com,  65797 <at> debbugs.gnu.org
> Date: Mon, 16 Oct 2023 12:33:10 -0400
> 
> > Sigh.  I guess we can install this on emacs-29 and cross the
> > fingers...
> 
> I'm not insisting on it.
> If you think it's risky, let's just have it on `master`.
> 
> BTW, see below the actual patch, including changes to etc/NEWS, manual,
> as well as the addition of a runtime warning (without which I can't see
> how we'll ever be able to get rid of the ugly backward compatibility
> hack).

Thanks.  I think we should install on master, indeed, and only
consider backporting if we hear about serious issues with the current
code on emacs-29.

> +The new semantics makes no such affordances, tho the code still
                                                ^^^
Typo.  Also, can we find a better (less rare) word instead of
"affordances"? 

Message #144 received at 65797-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, philipk <at> posteo.net, 65797-done <at> debbugs.gnu.org,
 mattias.engdegard <at> gmail.com, joseph <at> breatheoutbreathe.in
Subject: Re: bug#65797: `buffer-match-p` should not use `func-arity`
Date: Fri, 20 Oct 2023 22:52:00 -0400

> Thanks.  I think we should install on master, indeed, and only
> consider backporting if we hear about serious issues with the current
> code on emacs-29.

OK, pushed to `master`.
Closing.

>> +The new semantics makes no such affordances, tho the code still
>                                                 ^^^
> Typo.  Also, can we find a better (less rare) word instead of
> "affordances"? 

I think I did, yes.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.