GNU bug report logs - #79904
31.0.50; lispref: Fix function references and other issues

Previous Next

To reply to this bug, email your comments to 79904 AT debbugs.gnu.org.

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

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; lispref: Fix function references and other issues
Date: Thu, 27 Nov 2025 21:46:05 +0100

Recently I came across a number of possible issues in the Elisp
reference manual.  They are at least loosely related, so I collected
them in one bug.

Please let me know what you think.  Thanks!


General remarks:

- Most, but not all of these, are related to `@result's in the manual
  being different from what `C-x C-e' or `M-:' currently display for the
  original example.

  IOW, my expectation is that (by and large) I can evaluate an example
  in the manual by pressing `C-x C-e' after the example and then should
  get the result described in the manual.

  Not sure to what extent that expectation is justified.

- I included Stefan in the CC since some of the issues are related,
  IIUC, to his changes on closures and their printed representation.

- Whatever comes out of this, I would fix all issues in one commit.

- IMO fixing these in master only would be sufficient.


Questions:

- all lispref:

  There are a number of references to the `#f(...)' syntax for closures
  througout the manual in the example results.  Should I change these
  systematically to the current `#[...]' syntax?

- objects.texi/Special Read Syntax:

  This does not mention `#[...]' for closures, should I add something?


Concrete changes:

- This one missing blank should be obvious:

diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index 2721c2ce4a0..fccdc967e77 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -1678,7 +1678,7 @@ Function Cells
 @group
 (defun foo (x) x)
 (foo 1)
-     @result{}1
+     @result{} 1
 @end group
 @group
 (fmakunbound 'foo)


- Not sure about special characters in results:

@@ -1706,7 +1706,7 @@ Function Cells
 @example
 ;; @r{Define a named keyboard macro.}
 (fset 'kill-two-lines "\^u2\^k")
-     @result{} "\^u2\^k"
+     @result{} "^U2^K"
 @end example

 If you wish to use @code{fset} to make an alternate name for a


- The Texinfo manual recommends "see @ref" in contrast to "@pxref":

@@ -1746,7 +1746,7 @@ Closures

   The internal structure of a closure is an implementation matter and we
 recommend against examining or altering it directly.  For the curious,
-@pxref{Closure Objects}.
+see @ref{Closure Objects}.

 @node OClosures
 @section Open Closures


- Signals on `M-:' or `C-x C-e' in an "emacs -Q" differ from what the
  manual describes ...

diff --git a/doc/lispref/intro.texi b/doc/lispref/intro.texi
index a4695c9cb5d..e3337b9633c 100644
--- a/doc/lispref/intro.texi
+++ b/doc/lispref/intro.texi
@@ -276,10 +276,34 @@ Error Messages
 @subsection Error Messages
 @cindex error message notation

-  Some examples signal errors.  This normally displays an error message
-in the echo area.  We show the error message on a line starting with
-@samp{@error{}}.  Note that @samp{@error{}} itself does not appear in
-the echo area.
+  Some examples signal errors.  This normally enters the debugger in a
+separate buffer, showing the error backtrace (@pxref{The Lisp
+Debugger}):
+
+@example
+@group
+(+ 23 'x)
+@end group
+
+@group
+------ Buffer: *Backtrace* ------
+Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p x)
+  +(23 x)
+  (progn (+ 23 'x))
+  eval((progn (+ 23 'x)) t)
+  [... output elided ...]
+  funcall-interactively(eval-last-sexp nil)
+  command-execute(eval-last-sexp)
+------ Buffer: *Backtrace* ------
+@end group
+
+@end example
+
+  If @code{eval-expression-debug-on-error} equals nil, signals display
+an error message in the echo area instead.  Since such a message is more
+concise, this manual assumes that non-default behavior.  We show the
+error message on a line starting with @samp{@error{}}.  Note that
+@samp{@error{}} itself does not appear in the echo area.

 @example
 (+ 23 'x)


- Another result that does no longer look as described in the manual:

diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 44dd3bbb63c..9652f9b27cc 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -2847,16 +2847,13 @@ Batch Mode

 @group
 Error: error ("foo")
-mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x4f85c5
-7c45e2f81>))
-debug-early-backtrace()
-debug-early(error (error "foo"))
-signal(error ("foo"))
-error("foo")
-eval((error "foo") t)
-command-line-1(("--eval" "(error \"foo\")"))
-command-line()
-normal-top-level()
+  error("foo")
+  eval((error "foo") t)
+  command-line-1(("--eval" "(error \"foo\")"))
+  command-line()
+  normal-top-level()
+
+debug-early-backtrace...done
 @end group
 foo
 255


In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-11-27 built on sappc2
Repository revision: 4b4b48d019f146242184829ec222855432c959a5
Repository branch: fix-function-refs-results-other-issues
Windowing system distributor 'The X.Org Foundation', version 11.0.12401006
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure -C --build x86_64-linux-gnu --sharedstatedir=/var/lib
 --localstatedir=/var/lib --with-libsystemd --with-pop=yes
 --with-sound=alsa --without-gconf --with-mailutils --with-cairo
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 build_alias=x86_64-linux-gnu'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
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 WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_TIME: POSIX
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/jschmidt/work/org-mode/lisp/org-element-ast hides /home/jschmidt/work/emacs-master/lisp/org/org-element-ast
/home/jschmidt/work/org-mode/lisp/org-attach hides /home/jschmidt/work/emacs-master/lisp/org/org-attach
/home/jschmidt/work/org-mode/lisp/ob-scheme hides /home/jschmidt/work/emacs-master/lisp/org/ob-scheme
/home/jschmidt/work/org-mode/lisp/ob-processing hides /home/jschmidt/work/emacs-master/lisp/org/ob-processing
/home/jschmidt/work/org-mode/lisp/ob-gnuplot hides /home/jschmidt/work/emacs-master/lisp/org/ob-gnuplot
/home/jschmidt/work/org-mode/lisp/org-element hides /home/jschmidt/work/emacs-master/lisp/org/org-element
/home/jschmidt/work/org-mode/lisp/ob-org hides /home/jschmidt/work/emacs-master/lisp/org/ob-org
/home/jschmidt/work/org-mode/lisp/ob-sql hides /home/jschmidt/work/emacs-master/lisp/org/ob-sql
/home/jschmidt/work/org-mode/lisp/oc-bibtex hides /home/jschmidt/work/emacs-master/lisp/org/oc-bibtex
/home/jschmidt/work/org-mode/lisp/ox-koma-letter hides /home/jschmidt/work/emacs-master/lisp/org/ox-koma-letter
/home/jschmidt/work/org-mode/lisp/ox-icalendar hides /home/jschmidt/work/emacs-master/lisp/org/ox-icalendar
/home/jschmidt/work/org-mode/lisp/ol-gnus hides /home/jschmidt/work/emacs-master/lisp/org/ol-gnus
/home/jschmidt/work/org-mode/lisp/ob-sqlite hides /home/jschmidt/work/emacs-master/lisp/org/ob-sqlite
/home/jschmidt/work/org-mode/lisp/ob-clojure hides /home/jschmidt/work/emacs-master/lisp/org/ob-clojure
/home/jschmidt/work/org-mode/lisp/org-indent hides /home/jschmidt/work/emacs-master/lisp/org/org-indent
/home/jschmidt/work/org-mode/lisp/org-persist hides /home/jschmidt/work/emacs-master/lisp/org/org-persist
/home/jschmidt/work/org-mode/lisp/ol-eww hides /home/jschmidt/work/emacs-master/lisp/org/ol-eww
/home/jschmidt/work/org-mode/lisp/ol-info hides /home/jschmidt/work/emacs-master/lisp/org/ol-info
/home/jschmidt/work/org-mode/lisp/ol-rmail hides /home/jschmidt/work/emacs-master/lisp/org/ol-rmail
/home/jschmidt/work/org-mode/lisp/oc-basic hides /home/jschmidt/work/emacs-master/lisp/org/oc-basic
/home/jschmidt/work/org-mode/lisp/ob-forth hides /home/jschmidt/work/emacs-master/lisp/org/ob-forth
/home/jschmidt/work/org-mode/lisp/org-timer hides /home/jschmidt/work/emacs-master/lisp/org/org-timer
/home/jschmidt/work/org-mode/lisp/ob-makefile hides /home/jschmidt/work/emacs-master/lisp/org/ob-makefile
/home/jschmidt/work/org-mode/lisp/ob-fortran hides /home/jschmidt/work/emacs-master/lisp/org/ob-fortran
/home/jschmidt/work/org-mode/lisp/ox-html hides /home/jschmidt/work/emacs-master/lisp/org/ox-html
/home/jschmidt/work/org-mode/lisp/ob-lob hides /home/jschmidt/work/emacs-master/lisp/org/ob-lob
/home/jschmidt/work/org-mode/lisp/org-plot hides /home/jschmidt/work/emacs-master/lisp/org/org-plot
/home/jschmidt/work/org-mode/lisp/ob-js hides /home/jschmidt/work/emacs-master/lisp/org/ob-js
/home/jschmidt/work/org-mode/lisp/ob-R hides /home/jschmidt/work/emacs-master/lisp/org/ob-R
/home/jschmidt/work/org-mode/lisp/org-inlinetask hides /home/jschmidt/work/emacs-master/lisp/org/org-inlinetask
/home/jschmidt/work/org-mode/lisp/ol-mhe hides /home/jschmidt/work/emacs-master/lisp/org/ol-mhe
/home/jschmidt/work/org-mode/lisp/ob-dot hides /home/jschmidt/work/emacs-master/lisp/org/ob-dot
/home/jschmidt/work/org-mode/lisp/ol-docview hides /home/jschmidt/work/emacs-master/lisp/org/ol-docview
/home/jschmidt/work/org-mode/lisp/ob-C hides /home/jschmidt/work/emacs-master/lisp/org/ob-C
/home/jschmidt/work/org-mode/lisp/ol-man hides /home/jschmidt/work/emacs-master/lisp/org/ol-man
/home/jschmidt/work/org-mode/lisp/org-cycle hides /home/jschmidt/work/emacs-master/lisp/org/org-cycle
/home/jschmidt/work/org-mode/lisp/org-pcomplete hides /home/jschmidt/work/emacs-master/lisp/org/org-pcomplete
/home/jschmidt/work/org-mode/lisp/org-faces hides /home/jschmidt/work/emacs-master/lisp/org/org-faces
/home/jschmidt/work/org-mode/lisp/org hides /home/jschmidt/work/emacs-master/lisp/org/org
/home/jschmidt/work/org-mode/lisp/ol hides /home/jschmidt/work/emacs-master/lisp/org/ol
/home/jschmidt/work/org-mode/lisp/ob-haskell hides /home/jschmidt/work/emacs-master/lisp/org/ob-haskell
/home/jschmidt/work/org-mode/lisp/ob-lisp hides /home/jschmidt/work/emacs-master/lisp/org/ob-lisp
/home/jschmidt/work/org-mode/lisp/org-mobile hides /home/jschmidt/work/emacs-master/lisp/org/org-mobile
/home/jschmidt/work/org-mode/lisp/org-agenda hides /home/jschmidt/work/emacs-master/lisp/org/org-agenda
/home/jschmidt/work/org-mode/lisp/ob-perl hides /home/jschmidt/work/emacs-master/lisp/org/ob-perl
/home/jschmidt/work/org-mode/lisp/org-lint hides /home/jschmidt/work/emacs-master/lisp/org/org-lint
/home/jschmidt/work/org-mode/lisp/org-id hides /home/jschmidt/work/emacs-master/lisp/org/org-id
/home/jschmidt/work/org-mode/lisp/ox-man hides /home/jschmidt/work/emacs-master/lisp/org/ox-man
/home/jschmidt/work/org-mode/lisp/ol-bbdb hides /home/jschmidt/work/emacs-master/lisp/org/ol-bbdb
/home/jschmidt/work/org-mode/lisp/ob-lilypond hides /home/jschmidt/work/emacs-master/lisp/org/ob-lilypond
/home/jschmidt/work/org-mode/lisp/org-archive hides /home/jschmidt/work/emacs-master/lisp/org/org-archive
/home/jschmidt/work/org-mode/lisp/ox-publish hides /home/jschmidt/work/emacs-master/lisp/org/ox-publish
/home/jschmidt/work/org-mode/lisp/ob-core hides /home/jschmidt/work/emacs-master/lisp/org/ob-core
/home/jschmidt/work/org-mode/lisp/ob-groovy hides /home/jschmidt/work/emacs-master/lisp/org/ob-groovy
/home/jschmidt/work/org-mode/lisp/ox-org hides /home/jschmidt/work/emacs-master/lisp/org/ox-org
/home/jschmidt/work/org-mode/lisp/org-entities hides /home/jschmidt/work/emacs-master/lisp/org/org-entities
/home/jschmidt/work/org-mode/lisp/org-goto hides /home/jschmidt/work/emacs-master/lisp/org/org-goto
/home/jschmidt/work/org-mode/lisp/ob-awk hides /home/jschmidt/work/emacs-master/lisp/org/ob-awk
/home/jschmidt/work/org-mode/lisp/ol-eshell hides /home/jschmidt/work/emacs-master/lisp/org/ol-eshell
/home/jschmidt/work/org-mode/lisp/org-num hides /home/jschmidt/work/emacs-master/lisp/org/org-num
/home/jschmidt/work/org-mode/lisp/oc-csl hides /home/jschmidt/work/emacs-master/lisp/org/oc-csl
/home/jschmidt/work/org-mode/lisp/org-capture hides /home/jschmidt/work/emacs-master/lisp/org/org-capture
/home/jschmidt/work/org-mode/lisp/ob-ref hides /home/jschmidt/work/emacs-master/lisp/org/ob-ref
/home/jschmidt/work/org-mode/lisp/org-list hides /home/jschmidt/work/emacs-master/lisp/org/org-list
/home/jschmidt/work/org-mode/lisp/org-macro hides /home/jschmidt/work/emacs-master/lisp/org/org-macro
/home/jschmidt/work/org-mode/lisp/org-clock hides /home/jschmidt/work/emacs-master/lisp/org/org-clock
/home/jschmidt/work/org-mode/lisp/ob-table hides /home/jschmidt/work/emacs-master/lisp/org/ob-table
/home/jschmidt/work/org-mode/lisp/org-datetree hides /home/jschmidt/work/emacs-master/lisp/org/org-datetree
/home/jschmidt/work/org-mode/lisp/org-mouse hides /home/jschmidt/work/emacs-master/lisp/org/org-mouse
/home/jschmidt/work/org-mode/lisp/ob-latex hides /home/jschmidt/work/emacs-master/lisp/org/ob-latex
/home/jschmidt/work/org-mode/lisp/org-keys hides /home/jschmidt/work/emacs-master/lisp/org/org-keys
/home/jschmidt/work/org-mode/lisp/org-compat hides /home/jschmidt/work/emacs-master/lisp/org/org-compat
/home/jschmidt/work/org-mode/lisp/org-habit hides /home/jschmidt/work/emacs-master/lisp/org/org-habit
/home/jschmidt/work/org-mode/lisp/org-tempo hides /home/jschmidt/work/emacs-master/lisp/org/org-tempo
/home/jschmidt/work/org-mode/lisp/org-refile hides /home/jschmidt/work/emacs-master/lisp/org/org-refile
/home/jschmidt/work/org-mode/lisp/ob-ruby hides /home/jschmidt/work/emacs-master/lisp/org/ob-ruby
/home/jschmidt/work/org-mode/lisp/org-attach-git hides /home/jschmidt/work/emacs-master/lisp/org/org-attach-git
/home/jschmidt/work/org-mode/lisp/org-loaddefs hides /home/jschmidt/work/emacs-master/lisp/org/org-loaddefs
/home/jschmidt/work/org-mode/lisp/org-duration hides /home/jschmidt/work/emacs-master/lisp/org/org-duration
/home/jschmidt/work/org-mode/lisp/ob-ocaml hides /home/jschmidt/work/emacs-master/lisp/org/ob-ocaml
/home/jschmidt/work/org-mode/lisp/org-fold hides /home/jschmidt/work/emacs-master/lisp/org/org-fold
/home/jschmidt/work/org-mode/lisp/ox-ascii hides /home/jschmidt/work/emacs-master/lisp/org/ox-ascii
/home/jschmidt/work/org-mode/lisp/ob-css hides /home/jschmidt/work/emacs-master/lisp/org/ob-css
/home/jschmidt/work/org-mode/lisp/ob-tangle hides /home/jschmidt/work/emacs-master/lisp/org/ob-tangle
/home/jschmidt/work/org-mode/lisp/ob-python hides /home/jschmidt/work/emacs-master/lisp/org/ob-python
/home/jschmidt/work/org-mode/lisp/org-crypt hides /home/jschmidt/work/emacs-master/lisp/org/org-crypt
/home/jschmidt/work/org-mode/lisp/ol-bibtex hides /home/jschmidt/work/emacs-master/lisp/org/ol-bibtex
/home/jschmidt/work/org-mode/lisp/oc-biblatex hides /home/jschmidt/work/emacs-master/lisp/org/oc-biblatex
/home/jschmidt/work/org-mode/lisp/org-protocol hides /home/jschmidt/work/emacs-master/lisp/org/org-protocol
/home/jschmidt/work/org-mode/lisp/org-feed hides /home/jschmidt/work/emacs-master/lisp/org/org-feed
/home/jschmidt/work/org-mode/lisp/ob-maxima hides /home/jschmidt/work/emacs-master/lisp/org/ob-maxima
/home/jschmidt/work/org-mode/lisp/org-colview hides /home/jschmidt/work/emacs-master/lisp/org/org-colview
/home/jschmidt/work/org-mode/lisp/ol-w3m hides /home/jschmidt/work/emacs-master/lisp/org/ol-w3m
/home/jschmidt/work/org-mode/lisp/ob-ditaa hides /home/jschmidt/work/emacs-master/lisp/org/ob-ditaa
/home/jschmidt/work/org-mode/lisp/ob-plantuml hides /home/jschmidt/work/emacs-master/lisp/org/ob-plantuml
/home/jschmidt/work/org-mode/lisp/org-src hides /home/jschmidt/work/emacs-master/lisp/org/org-src
/home/jschmidt/work/org-mode/lisp/ob-sed hides /home/jschmidt/work/emacs-master/lisp/org/ob-sed
/home/jschmidt/work/org-mode/lisp/ox-latex hides /home/jschmidt/work/emacs-master/lisp/org/ox-latex
/home/jschmidt/work/org-mode/lisp/ob-exp hides /home/jschmidt/work/emacs-master/lisp/org/ob-exp
/home/jschmidt/work/org-mode/lisp/ob-lua hides /home/jschmidt/work/emacs-master/lisp/org/ob-lua
/home/jschmidt/work/org-mode/lisp/ox hides /home/jschmidt/work/emacs-master/lisp/org/ox
/home/jschmidt/work/org-mode/lisp/org-footnote hides /home/jschmidt/work/emacs-master/lisp/org/org-footnote
/home/jschmidt/work/org-mode/lisp/ol-doi hides /home/jschmidt/work/emacs-master/lisp/org/ol-doi
/home/jschmidt/work/org-mode/lisp/ob-emacs-lisp hides /home/jschmidt/work/emacs-master/lisp/org/ob-emacs-lisp
/home/jschmidt/work/org-mode/lisp/ox-odt hides /home/jschmidt/work/emacs-master/lisp/org/ox-odt
/home/jschmidt/work/org-mode/lisp/ob-eval hides /home/jschmidt/work/emacs-master/lisp/org/ob-eval
/home/jschmidt/work/org-mode/lisp/ob-matlab hides /home/jschmidt/work/emacs-master/lisp/org/ob-matlab
/home/jschmidt/work/org-mode/lisp/ob-sass hides /home/jschmidt/work/emacs-master/lisp/org/ob-sass
/home/jschmidt/work/org-mode/lisp/ob-java hides /home/jschmidt/work/emacs-master/lisp/org/ob-java
/home/jschmidt/work/org-mode/lisp/ob-julia hides /home/jschmidt/work/emacs-master/lisp/org/ob-julia
/home/jschmidt/work/org-mode/lisp/org-version hides /home/jschmidt/work/emacs-master/lisp/org/org-version
/home/jschmidt/work/org-mode/lisp/ob-calc hides /home/jschmidt/work/emacs-master/lisp/org/ob-calc
/home/jschmidt/work/org-mode/lisp/org-table hides /home/jschmidt/work/emacs-master/lisp/org/org-table
/home/jschmidt/work/org-mode/lisp/ol-irc hides /home/jschmidt/work/emacs-master/lisp/org/ol-irc
/home/jschmidt/work/org-mode/lisp/ob-eshell hides /home/jschmidt/work/emacs-master/lisp/org/ob-eshell
/home/jschmidt/work/org-mode/lisp/org-fold-core hides /home/jschmidt/work/emacs-master/lisp/org/org-fold-core
/home/jschmidt/work/org-mode/lisp/org-macs hides /home/jschmidt/work/emacs-master/lisp/org/org-macs
/home/jschmidt/work/org-mode/lisp/ob-comint hides /home/jschmidt/work/emacs-master/lisp/org/ob-comint
/home/jschmidt/work/org-mode/lisp/ox-texinfo hides /home/jschmidt/work/emacs-master/lisp/org/ox-texinfo
/home/jschmidt/work/org-mode/lisp/oc-natbib hides /home/jschmidt/work/emacs-master/lisp/org/oc-natbib
/home/jschmidt/work/org-mode/lisp/ob-screen hides /home/jschmidt/work/emacs-master/lisp/org/ob-screen
/home/jschmidt/work/org-mode/lisp/ox-beamer hides /home/jschmidt/work/emacs-master/lisp/org/ox-beamer
/home/jschmidt/work/org-mode/lisp/ob-octave hides /home/jschmidt/work/emacs-master/lisp/org/ob-octave
/home/jschmidt/work/org-mode/lisp/ob hides /home/jschmidt/work/emacs-master/lisp/org/ob
/home/jschmidt/work/org-mode/lisp/ob-shell hides /home/jschmidt/work/emacs-master/lisp/org/ob-shell
/home/jschmidt/work/org-mode/lisp/ox-md hides /home/jschmidt/work/emacs-master/lisp/org/ox-md
/home/jschmidt/work/org-mode/lisp/oc hides /home/jschmidt/work/emacs-master/lisp/org/oc
/home/jschmidt/work/org-mode/lisp/org-ctags hides /home/jschmidt/work/emacs-master/lisp/org/org-ctags

Features:
(shadow sort mail-extr emacsbug lisp-mnt message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader sendmail mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils comp-run comp-common rx time delsel
cus-start cus-load vc-git diff-mode track-changes easy-mmode
vc-dispatcher bug-reference go-mode find-file ffap thingatpt etags
fileloop generator xref project compile text-property-search comint
ansi-osc ansi-color ring files-x bc-dot-emacs warnings loadhist help-fns
radix-tree help-mode patch find-func csv-mode-autoloads
debbugs-autoloads git-modes-autoloads gnuplot-mode-autoloads
go-mode-autoloads goto-last-change-autoloads graphql-mode-autoloads
htmlize-autoloads magit-autoloads pcase magit-section-autoloads
llama-autoloads cond-let-autoloads markdown-mode-autoloads
polymode-autoloads simple-httpd-autoloads smart-tabs-mode-autoloads info
with-editor-autoloads yaml-mode-autoloads package browse-url xdg 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 icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 183505 32910) (symbols 48 30661 7)
 (strings 32 122052 4645) (string-bytes 1 3136821)
 (vectors 16 31866) (vector-slots 8 414268 14848)
 (floats 8 68 178) (intervals 56 412 43) (buffers 1064 13))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: monnier <at> iro.umontreal.ca, 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50;
 lispref: Fix function references and other issues
Date: Fri, 28 Nov 2025 09:28:57 +0200

> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> Date: Thu, 27 Nov 2025 21:46:05 +0100
> 
> Recently I came across a number of possible issues in the Elisp
> reference manual.  They are at least loosely related, so I collected
> them in one bug.
> 
> Please let me know what you think.  Thanks!

Thanks for working on these clean-ups of the manual.

> - Most, but not all of these, are related to `@result's in the manual
>   being different from what `C-x C-e' or `M-:' currently display for the
>   original example.
> 
>   IOW, my expectation is that (by and large) I can evaluate an example
>   in the manual by pressing `C-x C-e' after the example and then should
>   get the result described in the manual.
> 
>   Not sure to what extent that expectation is justified.

The manual should be reasonably accurate in this area.  It could
deviate from the reality where the exact result depends on
system-dependent factors (i.e. if the result is not identical in all
the builds).

> - all lispref:
> 
>   There are a number of references to the `#f(...)' syntax for closures
>   througout the manual in the example results.  Should I change these
>   systematically to the current `#[...]' syntax?

I think so.

> - objects.texi/Special Read Syntax:
> 
>   This does not mention `#[...]' for closures, should I add something?

Yes, IMO.

> - Not sure about special characters in results:
> 
> @@ -1706,7 +1706,7 @@ Function Cells
>  @example
>  ;; @r{Define a named keyboard macro.}
>  (fset 'kill-two-lines "\^u2\^k")
> -     @result{} "\^u2\^k"
> +     @result{} "^U2^K"
>  @end example

It's better to fix this, so it matches what is actually shown.

> - The Texinfo manual recommends "see @ref" in contrast to "@pxref":

That's a recommendation, not a hard rule.

> @@ -1746,7 +1746,7 @@ Closures
> 
>    The internal structure of a closure is an implementation matter and we
>  recommend against examining or altering it directly.  For the curious,
> -@pxref{Closure Objects}.
> +see @ref{Closure Objects}.

I would leave these alone.  @pxref at the end of a sentence is okay.

> -  Some examples signal errors.  This normally displays an error message
> -in the echo area.  We show the error message on a line starting with
> -@samp{@error{}}.  Note that @samp{@error{}} itself does not appear in
> -the echo area.
> +  Some examples signal errors.  This normally enters the debugger in a
> +separate buffer, showing the error backtrace (@pxref{The Lisp
> +Debugger}):
> +
> +@example
> +@group
> +(+ 23 'x)
> +@end group
> +
> +@group
> +------ Buffer: *Backtrace* ------
> +Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p x)
> +  +(23 x)
> +  (progn (+ 23 'x))
> +  eval((progn (+ 23 'x)) t)
> +  [... output elided ...]
> +  funcall-interactively(eval-last-sexp nil)
> +  command-execute(eval-last-sexp)
> +------ Buffer: *Backtrace* ------
> +@end group
> +
> +@end example
> +
> +  If @code{eval-expression-debug-on-error} equals nil, signals display
> +an error message in the echo area instead.  Since such a message is more
> +concise, this manual assumes that non-default behavior.  We show the
> +error message on a line starting with @samp{@error{}}.  Note that
> +@samp{@error{}} itself does not appear in the echo area.

This is okay, but perhaps is more appropriate for a @footnote than for
the mainline text.

> - Another result that does no longer look as described in the manual:
> 
> diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
> index 44dd3bbb63c..9652f9b27cc 100644
> --- a/doc/lispref/os.texi
> +++ b/doc/lispref/os.texi
> @@ -2847,16 +2847,13 @@ Batch Mode
> 
>  @group
>  Error: error ("foo")
> -mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x4f85c5
> -7c45e2f81>))
> -debug-early-backtrace()
> -debug-early(error (error "foo"))
> -signal(error ("foo"))
> -error("foo")
> -eval((error "foo") t)
> -command-line-1(("--eval" "(error \"foo\")"))
> -command-line()
> -normal-top-level()
> +  error("foo")
> +  eval((error "foo") t)
> +  command-line-1(("--eval" "(error \"foo\")"))
> +  command-line()
> +  normal-top-level()
> +
> +debug-early-backtrace...done
>  @end group
>  foo
>  255

This is what happens when people change long-standing behavior, but
don't make sure that the corresponding description(s) in the manual(s)
are adjusted to follow suit.  The above, in particular, is AFAIU due
to a recent change in how we process errors in batch mode.  Thanks for
finding this discrepancy.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Fri, 28 Nov 2025 08:48:48 -0500

>   There are a number of references to the `#f(...)' syntax for closures
>   througout the manual in the example results.  Should I change these
>   systematically to the current `#[...]' syntax?

Sadly "the current syntax" is a misleading formulation because there are
*two* printed representations: one from `prin1` and one from `cl-prin1`.
Some commands use one others use the other.  🙁

`#f(...)` is the one that comes out of `cl-prin1` and is the one that's
meant to be human-consumed, while `#[...]` is the "internal one" that's
meant to be read by Emacs.  IMO, we should reduce the current UI
inconsistency by using `cl-prin1` in more places.

> @@ -1706,7 +1706,7 @@ Function Cells
>  @example
>  ;; @r{Define a named keyboard macro.}
>  (fset 'kill-two-lines "\^u2\^k")
> -     @result{} "\^u2\^k"
> +     @result{} "^U2^K"
>  @end example

I think we should not advertise the use of strings&vectors as commands
(Emacs itself hasn't been using them since 2002 when we integrated Kim's
`kmacro.el`), and use `kmacro` instead:

    (fset 'kill-two-lines (kmacro "C-u 2 C-k"))
    => #f(kmacro "C-u 2 C-k")

[ Oh, and we should discourage the use of `fset` here, preferring `defalias`
  instead (`fset` is a lower-level function).  ]


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: jschmidt4gnu <at> vodafonemail.de, 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Fri, 28 Nov 2025 16:34:59 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 79904 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 28 Nov 2025 08:48:48 -0500
> 
> >   There are a number of references to the `#f(...)' syntax for closures
> >   througout the manual in the example results.  Should I change these
> >   systematically to the current `#[...]' syntax?
> 
> Sadly "the current syntax" is a misleading formulation because there are
> *two* printed representations: one from `prin1` and one from `cl-prin1`.
> Some commands use one others use the other.  🙁
> 
> `#f(...)` is the one that comes out of `cl-prin1` and is the one that's
> meant to be human-consumed, while `#[...]` is the "internal one" that's
> meant to be read by Emacs.  IMO, we should reduce the current UI
> inconsistency by using `cl-prin1` in more places.

But the ELisp manual documents the "read syntax", so I think we need
to document the "internal one".

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

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sat, 29 Nov 2025 12:16:52 +0100

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

>>   There are a number of references to the `#f(...)' syntax for closures
>>   througout the manual in the example results.  Should I change these
>>   systematically to the current `#[...]' syntax?
>
> Sadly "the current syntax" is a misleading formulation because there are
> *two* printed representations: one from `prin1` and one from `cl-prin1`.
> Some commands use one others use the other.  🙁
>
> `#f(...)` is the one that comes out of `cl-prin1` and is the one that's
> meant to be human-consumed, while `#[...]` is the "internal one" that's
> meant to be read by Emacs.  IMO, we should reduce the current UI
> inconsistency by using `cl-prin1` in more places.

I agree that `#f(...)' is in fact more human-readable, in particular
with that explicit :dynamic cookie.  But it required your mail for me to
find a way to actually generate that representation of closures.  All
the usual candidates to quickly evaluate some example (`eval-last-sexp',
`eval-defun', `eval-expression') print the "internal representation",
and I guess it will be hard to change that.

So what should we offer readers of the Elisp manual?  Advice to use
`eval-last-sexp' *except* for lambdas if they'd like to reproduce the
examples?  Or a note in the introduction on how to generate the
`#f(...)' syntax?  Or something like this in section "Closures":

modified   doc/lispref/functions.texi
@@ -1740,10 +1727,18 @@ Closures
 
 @example
 ;; @r{lexical binding is enabled.}
-(lambda (x) (* x x))
-     @result{} #f(lambda (x) [t] (* x x))
+(lambda (x) (* x y))
+     @result{} #[(x) ((* x y)) (t)]
 @end example
 
+  Above representation of closures (@code{#[@dots{}]}) is written by
+function @code{prin1}; it is meant to be read by Emacs.  Function
+@code{cl-prin1} writes a representation of closures that is more
+human-readable:
+
+[ What to provide here?  There is no such thing like `cl-print-eval'
+  that would do the job of `eval-expression'. ]
+
   The internal structure of a closure is an implementation matter and we
 recommend against examining or altering it directly.  For the curious,
 @pxref{Closure Objects}.

I guess the easiest approach would be to just use the `#(...)' notation.

>> @@ -1706,7 +1706,7 @@ Function Cells
>>  @example
>>  ;; @r{Define a named keyboard macro.}
>>  (fset 'kill-two-lines "\^u2\^k")
>> -     @result{} "\^u2\^k"
>> +     @result{} "^U2^K"
>>  @end example
>
> I think we should not advertise the use of strings&vectors as commands
> (Emacs itself hasn't been using them since 2002 when we integrated Kim's
> `kmacro.el`), and use `kmacro` instead:
>
>     (fset 'kill-two-lines (kmacro "C-u 2 C-k"))
>     => #f(kmacro "C-u 2 C-k")
>
> [ Oh, and we should discourage the use of `fset` here, preferring `defalias`
>   instead (`fset` is a lower-level function).  ]

While I share your objections in general, in the context of that
particular section of the Elisp manual ((elisp) Function Cells) I think
above example makes sense:

- It is in particular function `fset' which is described here (with a
  reference to `defalias' as an alternative in certain cases), and

- the example should just show (as simply as possible AFAIU) that it is
  possible to give "a symbol a function definition that is not a
  function".

If we really wanted to refer to kmacro.el, then probably from section
(elisp) Keyboard Macros.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>,  Eli Zaretskii <eliz <at> gnu.org>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 11:31:17 +0000

Hello,

On Fri 28 Nov 2025 at 08:48am -05, Stefan Monnier wrote:

>> @@ -1706,7 +1706,7 @@ Function Cells
>>  @example
>>  ;; @r{Define a named keyboard macro.}
>>  (fset 'kill-two-lines "\^u2\^k")
>> -     @result{} "\^u2\^k"
>> +     @result{} "^U2^K"
>>  @end example
>
> I think we should not advertise the use of strings&vectors as commands
> (Emacs itself hasn't been using them since 2002 when we integrated Kim's
> `kmacro.el`), and use `kmacro` instead:
>
>     (fset 'kill-two-lines (kmacro "C-u 2 C-k"))
>     => #f(kmacro "C-u 2 C-k")
>
> [ Oh, and we should discourage the use of `fset` here, preferring `defalias`
>   instead (`fset` is a lower-level function).  ]

It's really very convenient in init files to define things this way,
though, even if we don't want real packages doing it.

For example I have

    (global-set-key "\C-cj" "\M-j\C-u\C-ce")

-- 
Sean Whitton

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 08:07:50 -0500

>>> @@ -1706,7 +1706,7 @@ Function Cells
>>>  @example
>>>  ;; @r{Define a named keyboard macro.}
>>>  (fset 'kill-two-lines "\^u2\^k")
>>> -     @result{} "\^u2\^k"
>>> +     @result{} "^U2^K"
>>>  @end example
>>
>> I think we should not advertise the use of strings&vectors as commands
>> (Emacs itself hasn't been using them since 2002 when we integrated Kim's
>> `kmacro.el`), and use `kmacro` instead:
>>
>>     (fset 'kill-two-lines (kmacro "C-u 2 C-k"))
>>     => #f(kmacro "C-u 2 C-k")
>>
>> [ Oh, and we should discourage the use of `fset` here, preferring `defalias`
>>   instead (`fset` is a lower-level function).  ]
>
> It's really very convenient in init files to define things this way,
> though, even if we don't want real packages doing it.
>
> For example I have
>
>     (global-set-key "\C-cj" "\M-j\C-u\C-ce")

In which way is this more convenient than

    (global-set-key "\C-cj" (kmacro "M-j C-u C-c e"))

?


        Stefan

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 13:11:39 +0000

Hello,

On Sun 30 Nov 2025 at 08:07am -05, Stefan Monnier wrote:

>>>> @@ -1706,7 +1706,7 @@ Function Cells
>>>>  @example
>>>>  ;; @r{Define a named keyboard macro.}
>>>>  (fset 'kill-two-lines "\^u2\^k")
>>>> -     @result{} "\^u2\^k"
>>>> +     @result{} "^U2^K"
>>>>  @end example
>>>
>>> I think we should not advertise the use of strings&vectors as commands
>>> (Emacs itself hasn't been using them since 2002 when we integrated Kim's
>>> `kmacro.el`), and use `kmacro` instead:
>>>
>>>     (fset 'kill-two-lines (kmacro "C-u 2 C-k"))
>>>     => #f(kmacro "C-u 2 C-k")
>>>
>>> [ Oh, and we should discourage the use of `fset` here, preferring `defalias`
>>>   instead (`fset` is a lower-level function).  ]
>>
>> It's really very convenient in init files to define things this way,
>> though, even if we don't want real packages doing it.
>>
>> For example I have
>>
>>     (global-set-key "\C-cj" "\M-j\C-u\C-ce")
>
> In which way is this more convenient than
>
>     (global-set-key "\C-cj" (kmacro "M-j C-u C-c e"))

It's shorter, quicker to type if it's what you're used to.

For example, you'd have to remember to use kmacro instead of just kbd.

-- 
Sean Whitton

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 08:13:39 -0500

> In which way is this more convenient than
>
>     (global-set-key "\C-cj" (kmacro "M-j C-u C-c e"))
>
> ?

Or (keymap-global-set "C-c j" (kmacro "M-j C-u C-c e")),
[so it uses the same key syntax on both sides] ?


        Stefan

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 13:21:48 +0000

Hello,

On Sun 30 Nov 2025 at 08:13am -05, Stefan Monnier wrote:

>> In which way is this more convenient than
>>
>>     (global-set-key "\C-cj" (kmacro "M-j C-u C-c e"))
>>
>> ?
>
> Or (keymap-global-set "C-c j" (kmacro "M-j C-u C-c e")),
> [so it uses the same key syntax on both sides] ?

ISTM that knowing to use kmacro instead of kbd is an implementation
detail that it would be nice if init-writers didn't have to worry about.
As indeed they do not have to at present.

-- 
Sean Whitton

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Sun, 30 Nov 2025 09:23:19 -0500

> ISTM that knowing to use kmacro instead of kbd is an implementation
> detail that it would be nice if init-writers didn't have to worry about.
> As indeed they do not have to at present.

I see your point.  But that brings in extra complexity elsewhere.
E.g. the difference between `command-execute` and `call-interactively`,
the second argument to `commandp`, and more generally the fact that
`command` is not a subtype of `function`.  There are various places in
our codebase and external packages where this subtlety is not taken into
account and hence kmacros work but arrays of keys don't.
For this reason, I prefer to steer users towards kmacros.


        Stefan

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

From: Richard Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eliz <at> gnu.org, jschmidt4gnu <at> vodafonemail.de, 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50;
 lispref: Fix function references and other issues
Date: Mon, 01 Dec 2025 00:17:51 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Sadly "the current syntax" is a misleading formulation because there are
  > *two* printed representations: one from `prin1` and one from `cl-prin1`.

To have two different syntaxes for the same LIsp object is spurious
complexity and will cause confusion.  Let's fix this problem through
and through by choosing one of these two syntaxes.  It is ok to accept
both for input, if that is not hard.  But we should choose one as the
correct syntax.  We should output only that one, and document only
that one.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 79904 <at> debbugs.gnu.org
Subject: Re: bug#79904: 31.0.50; lispref: Fix function references and other
 issues
Date: Mon, 01 Dec 2025 12:02:16 +0000

Hello,

On Sun 30 Nov 2025 at 09:23am -05, Stefan Monnier wrote:

>> ISTM that knowing to use kmacro instead of kbd is an implementation
>> detail that it would be nice if init-writers didn't have to worry about.
>> As indeed they do not have to at present.
>
> I see your point.  But that brings in extra complexity elsewhere.
> E.g. the difference between `command-execute` and `call-interactively`,
> the second argument to `commandp`, and more generally the fact that
> `command` is not a subtype of `function`.

Right, though, we aren't ever likely to be able to deprecate this
feature because it has been in Emacs for such a long time.  I'm
certainly not advocating that, if we lacked it, it is a feature we
should add.

> There are various places in our codebase and external packages where
> this subtlety is not taken into account and hence kmacros work but
> arrays of keys don't.  For this reason, I prefer to steer users
> towards kmacros.

I agree, if that's the case.

-- 
Sean Whitton

Previous Next

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