bug#68375: 29.1; lispref documentation fixes

bug#68375: 29.1; lispref documentation fixes

[Xiyue Deng]

[-- Attachment #1: Type: text/plain, Size: 14125 bytes --]


Please find the attached patches for a cumulation of documentation fixes
for lispref up to chapter 19 that includes typos, formatting, etc.
Please let me know if any changes need improvements and I'll adjust
accordingly.


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37,
 cairo version 1.16.0) of 2023-09-19, modified by Debian built on
 debian-hx90
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/emacs-bYKTEl/emacs-29.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

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 WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

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

Major mode: VTerm

Minor modes in effect:
  TeX-PDF-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  windmove-mode: t
  rcirc-track-minor-mode: t
  server-mode: t
  global-company-mode: t
  company-mode: t
  global-treesit-auto-mode: t
  icomplete-mode: t
  fido-mode: t
  override-global-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: 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

Load-path shadows:
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-sources hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-sources
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-bug hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-bug
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/apt-utils hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/apt-utils
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/gnus-BTS hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/gnus-BTS
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/deb-view hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/deb-view
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/debian-el hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/debian-el
/usr/share/emacs/site-lisp/elpa/debian-el-37.11/preseed hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37.11/preseed
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-autoloads hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-autoloads
/usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-mode
/usr/share/emacs/site-lisp/elpa/devscripts-40/devscripts-pkg hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/devscripts-pkg
/usr/share/emacs/site-lisp/elpa/devscripts-40/pbuilder-log-view-mode hides /usr/share/emacs/site-lisp/elpa-src/devscripts-40/pbuilder-log-view-mode
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-autoloads
/usr/share/emacs/site-lisp/elpa/dockerfile-mode-1.7/dockerfile-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/dockerfile-mode-1.7/dockerfile-mode-pkg
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-bts-control hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-bts-control
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-changelog-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-changelog-mode
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-autoloads
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el-pkg
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/dpkg-dev-el hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/dpkg-dev-el
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-control-mode hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-control-mode
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/debian-copyright hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/debian-copyright
/usr/share/emacs/site-lisp/elpa/dpkg-dev-el-37.10/readme-debian hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.10/readme-debian
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-pkg hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-pkg
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian-autoloads
/usr/share/emacs/site-lisp/elpa/lintian-0.1/lintian hides /usr/share/emacs/site-lisp/elpa-src/lintian-0.1/lintian
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-pkg
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode-autoloads
/usr/share/emacs/site-lisp/elpa/po-mode-0.21/po-mode hides /usr/share/emacs/site-lisp/elpa-src/po-mode-0.21/po-mode
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-autoloads hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-autoloads
/usr/share/emacs/site-lisp/elpa/py-isort-2016.1/py-isort-pkg hides /usr/share/emacs/site-lisp/elpa-src/py-isort-2016.1/py-isort-pkg
/home/xiyueden/.config/emacs/elpa/transient-0.5.2/transient hides /usr/share/emacs/29.1/lisp/transient

Features:
(shadow emacsbug goto-addr generic generic-x find-dired ffap grep
display-fill-column-indicator cl-print edebug mule-diag rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap sgml-mode facemenu nxml-util nxml-enc xmltok
git-rebase debian-changelog-mode make-mode sh-script smie executable
conf-mode org-element org-persist org-id org-refile avl-tree oc-basic
ol-eww eww xdg mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m
ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-src ob-comint org-pcomplete org-list org-footnote
org-faces org-entities noutline outline ob-emacs-lisp ob-core ob-eval
org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs
cal-menu calendar cal-loaddefs org-version org-compat org-macs shortdoc
help-fns radix-tree eglot external-completion array jsonrpc ert ewoc
debug backtrace reporter debian-bug mailalias vterm magit-bookmark
bookmark tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat term ehelp find-func vterm-module yaml-ts-mode misearch
multi-isearch tex-info tex texmathp texinfo texinfo-loaddefs
magit-extras face-remap magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
git-commit log-edit add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor shell pcomplete magit-mode
transient edmacro kmacro compat format-spec magit-git magit-section
dired-aux url-http url-gw url-auth url-queue url-cache flow-fill matlab
matlab-scan matlab-syntax matlab-compat pulse sort gnus-cite shr-color
color qp mm-archive mail-extr textsec uni-scripts idna-mapping
ucs-normalize uni-confusable textsec-check gnus-async gnus-bcklg gnus-ml
magit-utils crm dash mule-util jka-compr gnus-topic cursor-sensor utf-7
nnfolder gnus-demon nnml ezgnus gnus-delay gnus-draft gnus-agent
gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
pixel-fill kinsoku url-file svg dom nndraft nnmh gnus-group gnus-undo
smtpmail gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail
yank-media dired dired-loaddefs rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range
mm-util mail-prsvr windmove flyspell ispell gnutls network-stream puny
nsm epa-file epa derived epg rfc6068 epg-config rcirc parse-time iso8601
time-date term/xterm xterm comp comp-cstr rx server cap-words superword
subword vc-hg vc-git diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs log-view pcvs-util vc vc-dispatcher bug-reference disp-table
whitespace yasnippet cus-edit pp cus-start wid-edit company-oddmuse
company-keywords company-etags etags fileloop generator xref
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company pcase init zenburn-theme
treesit-auto treesit keychain-environment exec-path-from-shell icomplete
cus-load flymake-proc flymake project compile text-property-search
comint ansi-osc ansi-color ring warnings icons thingatpt advice cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core display-line-numbers autorevert filenotify
apache-mode-autoloads auctex-autoloads tex-site bison-mode-autoloads
boxquote-autoloads cargo-autoloads cmake-mode-autoloads
company-autoloads csv-mode-autoloads dart-mode-autoloads
exec-path-from-shell-autoloads flutter-autoloads format-all-autoloads
git-modes-autoloads gnuplot-autoloads go-mode-autoloads
graphviz-dot-mode-autoloads inheritenv-autoloads
keychain-environment-autoloads language-id-autoloads magit-autoloads
git-commit-autoloads magit-section-autoloads dash-autoloads
matlab-mode-autoloads meson-mode-autoloads nginx-mode-autoloads
pyvenv-autoloads rust-mode-autoloads scala-mode-autoloads
transient-autoloads treesit-auto-autoloads vterm-autoloads
with-editor-autoloads compat-autoloads xclip-autoloads
yaml-mode-autoloads yasnippet-autoloads zenburn-theme-autoloads info
debian-el-autoloads dpkg-dev-el-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 4533683 389187)
 (symbols 48 61187 52)
 (strings 32 243158 43406)
 (string-bytes 1 8480325)
 (vectors 16 149096)
 (vector-slots 8 3677021 218025)
 (floats 8 1072 6391)
 (intervals 56 256432 8885)
 (buffers 984 114))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-typo-in-lispref-Buffer-Type-section.patch --]
[-- Type: text/x-diff, Size: 1098 bytes --]

From 5f5fe1888791aafc749b6655519a487e44014679 Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Tue, 19 Dec 2023 02:29:39 -0800
Subject: [PATCH 1/6] Fix typo in lispref "Buffer Type" section

* doc/lispref/objects.texi (Buffer Type): Fix typo.
---
 doc/lispref/objects.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/lispref/objects.texi b/doc/lispref/objects.texi
index 111beb5e5b0..6ee3f414abb 100644
--- a/doc/lispref/objects.texi
+++ b/doc/lispref/objects.texi
@@ -1573,7 +1573,7 @@ editing.
 (@pxref{Files}) so they can be edited, but some are used for other
 purposes.  Most buffers are also meant to be seen by the user, and
 therefore displayed, at some time, in a window (@pxref{Windows}).  But
-a buffer need not be displayed in any window.  Each buffer has a
+a buffer needs not be displayed in any window.  Each buffer has a
 designated position called @dfn{point} (@pxref{Positions}); most
 editing commands act on the contents of the current buffer in the
 neighborhood of point.  At any time, one buffer is the @dfn{current
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Fix-typo-in-lispref-String-Basics-section.patch --]
[-- Type: text/x-diff, Size: 997 bytes --]

From 2bcfb5415dcc54c78a93761239d4fb9fc9b09901 Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Wed, 20 Dec 2023 10:52:26 -0800
Subject: [PATCH 2/6] Fix typo in lispref "String Basics" section

* doc/lispref/strings.texi (String Basics): Fix typo.
---
 doc/lispref/strings.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi
index 7097de49064..4fe94f78cba 100644
--- a/doc/lispref/strings.texi
+++ b/doc/lispref/strings.texi
@@ -43,7 +43,7 @@ integer is a character or not is determined only by how it is used.
 Emacs.
 
   A string is a fixed sequence of characters.  It is a type of
-sequence called a @dfn{array}, meaning that its length is fixed and
+sequence called an @dfn{array}, meaning that its length is fixed and
 cannot be altered once it is created (@pxref{Sequences Arrays
 Vectors}).  Unlike in C, Emacs Lisp strings are @emph{not} terminated
 by a distinguished character code.
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Fix-typo-in-lispref-Creating-Strings-section.patch --]
[-- Type: text/x-diff, Size: 1430 bytes --]

From b15a219495933e5c5cb5031daf69ba8fad0afb61 Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Wed, 20 Dec 2023 11:26:13 -0800
Subject: [PATCH 3/6] Fix typo in lispref "Creating Strings" section

* doc/lispref/strings.texi (Creating Strings): Fix typo.
---
 doc/lispref/strings.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi
index 4fe94f78cba..02c266c6b1a 100644
--- a/doc/lispref/strings.texi
+++ b/doc/lispref/strings.texi
@@ -282,7 +282,7 @@ an error.  To obtain a string that you can safely mutate, use
 @code{copy-sequence} on the result.
 
 For information about other concatenation functions, see the
-description of @code{mapconcat} in @ref{Mapping Functions},
+descriptions of @code{mapconcat} in @ref{Mapping Functions},
 @code{vconcat} in @ref{Vector Functions}, and @code{append} in @ref{Building
 Lists}.  For concatenating individual command-line arguments into a
 string to be used as a shell command, see @ref{Shell Arguments,
@@ -366,7 +366,7 @@ three previous examples are rarely relevant:
      @result{} nil
 @end example
 
-Somewhat odd, but predictable, behavior can occur for certain
+A somewhat odd, but predictable, behavior can occur for certain
 ``non-greedy'' values of @var{separators} that can prefer empty
 matches over non-empty matches.  Again, such values rarely occur in
 practice:
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-Wrap-pxref-of-Abbrevs-in-parentheses.patch --]
[-- Type: text/x-diff, Size: 922 bytes --]

From fd8ce85a531be327bc0f5b41adfee078f608d251 Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Wed, 27 Dec 2023 12:35:39 -0800
Subject: [PATCH 4/6] Wrap @pxref of Abbrevs in parentheses

* doc/lispref/symbols.texi (Shorthands): Wrap `@pxref{Abbrevs}' in
parentheses.
---
 doc/lispref/symbols.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi
index 6fe4189901a..367bd195f16 100644
--- a/doc/lispref/symbols.texi
+++ b/doc/lispref/symbols.texi
@@ -675,7 +675,7 @@ name} (@pxref{Symbol Components}).
 
 It is useful to think of shorthands as @emph{abbreviating} the full
 names of intended symbols.  Despite this, do not confuse shorthands with the
-Abbrev system @pxref{Abbrevs}.
+Abbrev system (@pxref{Abbrevs}).
 
 @cindex namespace etiquette
 Shorthands make Emacs Lisp's @dfn{namespacing etiquette} easier to work
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-Fix-count-of-no-op-functions.patch --]
[-- Type: text/x-diff, Size: 1110 bytes --]

From 454ed28e302493d678d2306b908c9542a8491daa Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Tue, 2 Jan 2024 16:31:30 -0800
Subject: [PATCH 5/6] Fix count of no-op functions

It looks like there are actually three kinds of no-op functions.

* doc/lispref/functions.texi (Calling Functions): Fix count and
plural of no-op functions.
---
 doc/lispref/functions.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index 29e9f04a076..6c6f1e25917 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -982,8 +982,8 @@ lists) and call them using @code{funcall} or @code{apply}.  Functions
 that accept function arguments are often called @dfn{functionals}.
 
   Sometimes, when you call a functional, it is useful to supply a no-op
-function as the argument.  Here are two different kinds of no-op
-function:
+function as the argument.  Here are three different kinds of no-op
+functions:
 
 @defun identity argument
 This function returns @var{argument} and has no side effects.
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-Fix-unmatched-parentheses.patch --]
[-- Type: text/x-diff, Size: 2076 bytes --]

From 670612720f281fa8ada32626433ac209bba0de6b Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Wed, 10 Jan 2024 00:59:03 -0800
Subject: [PATCH 6/6] Fix unmatched parentheses

* doc/lispref/debugging.texi (Syntax Errors): Fix unmatched
parentheses.
---
 doc/lispref/debugging.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi
index 774fcaf68bf..bb31906753b 100644
--- a/doc/lispref/debugging.texi
+++ b/doc/lispref/debugging.texi
@@ -926,7 +926,7 @@ parenthesis or missing open parenthesis, but does not say where the
 missing parenthesis belongs.  How, then, to find what to change?
 
   If the problem is not simply an imbalance of parentheses, a useful
-technique is to try @kbd{C-M-e} (@code{end-of-defun}, @pxref{Moving by
+technique is to try @kbd{C-M-e} (@code{end-of-defun}), @pxref{Moving by
 Defuns,,,emacs, The GNU Emacs Manual}) at the beginning of each defun,
 and see if it goes to the place where that defun appears to end.  If
 it does not, there is a problem in that defun.
@@ -949,7 +949,7 @@ find the mismatch.)
 
   The first step is to find the defun that is unbalanced.  If there is
 an excess open parenthesis, the way to do this is to go to the end of
-the file and type @kbd{C-u C-M-u} (@code{backward-up-list},
+the file and type @kbd{C-u C-M-u} (@code{backward-up-list}),
 @pxref{Moving by Parens,,,emacs, The GNU Emacs Manual}).  This will
 move you to the beginning of the first defun that is unbalanced.
 
@@ -957,7 +957,7 @@ move you to the beginning of the first defun that is unbalanced.
 way to be sure of this except by studying the program, but often the
 existing indentation is a clue to where the parentheses should have
 been.  The easiest way to use this clue is to reindent with @kbd{C-M-q}
-(@code{indent-pp-sexp}, @pxref{Multi-line Indent,,,emacs, The GNU
+(@code{indent-pp-sexp}), @pxref{Multi-line Indent,,,emacs, The GNU
 Emacs Manual}) and see what moves.  @strong{But don't do this yet!}
 Keep reading, first.
 
-- 
2.39.2

bug#68375: 29.1; lispref documentation fixes

[Eli Zaretskii]

> From: Xiyue Deng <manphiz@gmail.com>
> Date: Wed, 10 Jan 2024 14:56:23 -0800
> 
> Please find the attached patches for a cumulation of documentation fixes
> for lispref up to chapter 19 that includes typos, formatting, etc.
> Please let me know if any changes need improvements and I'll adjust
> accordingly.

Thanks.  See below.

> --- a/doc/lispref/objects.texi
> +++ b/doc/lispref/objects.texi
> @@ -1573,7 +1573,7 @@ editing.
>  (@pxref{Files}) so they can be edited, but some are used for other
>  purposes.  Most buffers are also meant to be seen by the user, and
>  therefore displayed, at some time, in a window (@pxref{Windows}).  But
> -a buffer need not be displayed in any window.  Each buffer has a
> +a buffer needs not be displayed in any window.  Each buffer has a

This is not a typo: the wording here is correct English.  So I didn't
install this part.

>    A string is a fixed sequence of characters.  It is a type of
> -sequence called a @dfn{array}, meaning that its length is fixed and
> +sequence called an @dfn{array}, meaning that its length is fixed and

The "an" here is correct, since in a manual one sees "an array", which
is correct English.  So I didn't install this part.

>  For information about other concatenation functions, see the
> -description of @code{mapconcat} in @ref{Mapping Functions},
> +descriptions of @code{mapconcat} in @ref{Mapping Functions},

There's nothing wrong with using singular here, so I didn't install
this part.

> * doc/lispref/symbols.texi (Shorthands): Wrap `@pxref{Abbrevs}' in
> parentheses.

I installed this part.

> >From 454ed28e302493d678d2306b908c9542a8491daa Mon Sep 17 00:00:00 2001
> From: Xiyue Deng <manphiz@gmail.com>
> Date: Tue, 2 Jan 2024 16:31:30 -0800
> Subject: [PATCH 5/6] Fix count of no-op functions
> 
> It looks like there are actually three kinds of no-op functions.
> 
> * doc/lispref/functions.texi (Calling Functions): Fix count and
> plural of no-op functions.

I installed this part as well.

> * doc/lispref/debugging.texi (Syntax Errors): Fix unmatched
> parentheses.

I didn't install this part, because there's nothing wrong with
parentheses here.  Using @pxref as below:

>    If the problem is not simply an imbalance of parentheses, a useful
> -technique is to try @kbd{C-M-e} (@code{end-of-defun}, @pxref{Moving by
> +technique is to try @kbd{C-M-e} (@code{end-of-defun}), @pxref{Moving by
>  Defuns,,,emacs, The GNU Emacs Manual}) at the beginning of each defun,

is perfectly correct.  So I didn't install this part.

Please note that with this contribution we've exhausted the amount of
changes we can accept from you without a copyright assignment.  Would
you like to start the legal paperwork of assigning to the FSF the
copyright for your future contributions?  If so, I will send you the
form to fill and the instructions to email the filled form.

Thanks, I will now close this bug.

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Xiyue Deng <manphiz@gmail.com>
>> Date: Wed, 10 Jan 2024 14:56:23 -0800
>>
>> Please find the attached patches for a cumulation of documentation fixes
>> for lispref up to chapter 19 that includes typos, formatting, etc.
>> Please let me know if any changes need improvements and I'll adjust
>> accordingly.
>
> Thanks.  See below.
[...]
>>    A string is a fixed sequence of characters.  It is a type of
>> -sequence called a @dfn{array}, meaning that its length is fixed and
>> +sequence called an @dfn{array}, meaning that its length is fixed and
>
> The "an" here is correct, since in a manual one sees "an array", which
> is correct English.  So I didn't install this part.

You misread the patch, it changes "a" to "an", which makes the text
correct English.  I thought I'd save you some work by installing the
patch myself, which I just did, but unfortunately to master instead of
emacs-29 (and also forgot to add the bug number).  Should I revert it
and install to the release branch?  Sorry for the trouble.

Steve

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Xiyue Deng <manphiz@gmail.com>
>>> Date: Wed, 10 Jan 2024 14:56:23 -0800
>>>
>>> Please find the attached patches for a cumulation of documentation fixes
>>> for lispref up to chapter 19 that includes typos, formatting, etc.
>>> Please let me know if any changes need improvements and I'll adjust
>>> accordingly.
>>
>> Thanks.  See below.
> [...]
>>>    A string is a fixed sequence of characters.  It is a type of
>>> -sequence called a @dfn{array}, meaning that its length is fixed and
>>> +sequence called an @dfn{array}, meaning that its length is fixed and
>>
>> The "an" here is correct, since in a manual one sees "an array", which
>> is correct English.  So I didn't install this part.
>
> You misread the patch, it changes "a" to "an", which makes the text
> correct English.  I thought I'd save you some work by installing the
> patch myself, which I just did, but unfortunately to master instead of
> emacs-29 (and also forgot to add the bug number).  Should I revert it
> and install to the release branch?  Sorry for the trouble.

I went ahead and reverted the change on master and installed it on
emacs-29 (with bug number).

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 15:21:08 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Xiyue Deng <manphiz@gmail.com>
>>>> Date: Wed, 10 Jan 2024 14:56:23 -0800
>>>> 
>>>> Please find the attached patches for a cumulation of documentation fixes
>>>> for lispref up to chapter 19 that includes typos, formatting, etc.
>>>> Please let me know if any changes need improvements and I'll adjust
>>>> accordingly.
>>>
>>> Thanks.  See below.
>> [...]
>>>>    A string is a fixed sequence of characters.  It is a type of
>>>> -sequence called a @dfn{array}, meaning that its length is fixed and
>>>> +sequence called an @dfn{array}, meaning that its length is fixed and
>>>
>>> The "an" here is correct, since in a manual one sees "an array", which
>>> is correct English.  So I didn't install this part.
>>
>> You misread the patch, it changes "a" to "an", which makes the text
>> correct English.  I thought I'd save you some work by installing the
>> patch myself, which I just did, but unfortunately to master instead of
>> emacs-29 (and also forgot to add the bug number).  Should I revert it
>> and install to the release branch?  Sorry for the trouble.
>
> I went ahead and reverted the change on master and installed it on
> emacs-29 (with bug number).

... but without the "Copyright-paperwork-exempt: yes" cookie 😕.  Should
I revert again?  (This time I will not act without explicit permission.)

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: eliz@gnu.org,  manphiz@gmail.com
> Date: Thu, 11 Jan 2024 14:44:35 +0100
> 
> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Xiyue Deng <manphiz@gmail.com>
> >> Date: Wed, 10 Jan 2024 14:56:23 -0800
> >>
> >> Please find the attached patches for a cumulation of documentation fixes
> >> for lispref up to chapter 19 that includes typos, formatting, etc.
> >> Please let me know if any changes need improvements and I'll adjust
> >> accordingly.
> >
> > Thanks.  See below.
> [...]
> >>    A string is a fixed sequence of characters.  It is a type of
> >> -sequence called a @dfn{array}, meaning that its length is fixed and
> >> +sequence called an @dfn{array}, meaning that its length is fixed and
> >
> > The "an" here is correct, since in a manual one sees "an array", which
> > is correct English.  So I didn't install this part.
> 
> You misread the patch, it changes "a" to "an", which makes the text
> correct English.

Oops.

> I thought I'd save you some work by installing the patch myself,
> which I just did, but unfortunately to master instead of emacs-29
> (and also forgot to add the bug number).  Should I revert it and
> install to the release branch?  Sorry for the trouble.

You could have simply cherry-picked it to emacs-29.

bug#68375: 29.1; lispref documentation fixes

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: eliz@gnu.org,  manphiz@gmail.com
> Date: Thu, 11 Jan 2024 15:32:10 +0100
> 
> On Thu, 11 Jan 2024 15:21:08 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
> 
> > On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
> >
> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >>>> From: Xiyue Deng <manphiz@gmail.com>
> >>>> Date: Wed, 10 Jan 2024 14:56:23 -0800
> >>>> 
> >>>> Please find the attached patches for a cumulation of documentation fixes
> >>>> for lispref up to chapter 19 that includes typos, formatting, etc.
> >>>> Please let me know if any changes need improvements and I'll adjust
> >>>> accordingly.
> >>>
> >>> Thanks.  See below.
> >> [...]
> >>>>    A string is a fixed sequence of characters.  It is a type of
> >>>> -sequence called a @dfn{array}, meaning that its length is fixed and
> >>>> +sequence called an @dfn{array}, meaning that its length is fixed and
> >>>
> >>> The "an" here is correct, since in a manual one sees "an array", which
> >>> is correct English.  So I didn't install this part.
> >>
> >> You misread the patch, it changes "a" to "an", which makes the text
> >> correct English.  I thought I'd save you some work by installing the
> >> patch myself, which I just did, but unfortunately to master instead of
> >> emacs-29 (and also forgot to add the bug number).  Should I revert it
> >> and install to the release branch?  Sorry for the trouble.
> >
> > I went ahead and reverted the change on master and installed it on
> > emacs-29 (with bug number).
> 
> ... but without the "Copyright-paperwork-exempt: yes" cookie 😕.  Should
> I revert again?  (This time I will not act without explicit permission.)

It's too late, since reverting a change doesn't remove it from Git
history.

I hope Xiyue Deng will assign the copyright, which will then cover
this blunder.

Thanks.

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 16:51:39 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: eliz@gnu.org,  manphiz@gmail.com
>> Date: Thu, 11 Jan 2024 14:44:35 +0100
>>
>> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> >> From: Xiyue Deng <manphiz@gmail.com>
>> >> Date: Wed, 10 Jan 2024 14:56:23 -0800
>> >>
>> >> Please find the attached patches for a cumulation of documentation fixes
>> >> for lispref up to chapter 19 that includes typos, formatting, etc.
>> >> Please let me know if any changes need improvements and I'll adjust
>> >> accordingly.
>> >
>> > Thanks.  See below.
>> [...]
>> >>    A string is a fixed sequence of characters.  It is a type of
>> >> -sequence called a @dfn{array}, meaning that its length is fixed and
>> >> +sequence called an @dfn{array}, meaning that its length is fixed and
>> >
>> > The "an" here is correct, since in a manual one sees "an array", which
>> > is correct English.  So I didn't install this part.
>>
>> You misread the patch, it changes "a" to "an", which makes the text
>> correct English.
>
> Oops.
>
>> I thought I'd save you some work by installing the patch myself,
>> which I just did, but unfortunately to master instead of emacs-29
>> (and also forgot to add the bug number).  Should I revert it and
>> install to the release branch?  Sorry for the trouble.
>
> You could have simply cherry-picked it to emacs-29.

Is it possible to do that with VC?  I didn't find the term in the source
code, only in admin/notes/git-workflow, which only shows the git command
(and says to "add 'Backport:' to the commit string", which is another
attention block I could well stumble over...).

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 16:56:13 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: eliz@gnu.org,  manphiz@gmail.com
>> Date: Thu, 11 Jan 2024 15:32:10 +0100
>> 
>> On Thu, 11 Jan 2024 15:21:08 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>> 
>> > On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>> >
>> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> >>
>> >>>> From: Xiyue Deng <manphiz@gmail.com>
>> >>>> Date: Wed, 10 Jan 2024 14:56:23 -0800
>> >>>> 
>> >>>> Please find the attached patches for a cumulation of documentation fixes
>> >>>> for lispref up to chapter 19 that includes typos, formatting, etc.
>> >>>> Please let me know if any changes need improvements and I'll adjust
>> >>>> accordingly.
>> >>>
>> >>> Thanks.  See below.
>> >> [...]
>> >>>>    A string is a fixed sequence of characters.  It is a type of
>> >>>> -sequence called a @dfn{array}, meaning that its length is fixed and
>> >>>> +sequence called an @dfn{array}, meaning that its length is fixed and
>> >>>
>> >>> The "an" here is correct, since in a manual one sees "an array", which
>> >>> is correct English.  So I didn't install this part.
>> >>
>> >> You misread the patch, it changes "a" to "an", which makes the text
>> >> correct English.  I thought I'd save you some work by installing the
>> >> patch myself, which I just did, but unfortunately to master instead of
>> >> emacs-29 (and also forgot to add the bug number).  Should I revert it
>> >> and install to the release branch?  Sorry for the trouble.
>> >
>> > I went ahead and reverted the change on master and installed it on
>> > emacs-29 (with bug number).
>> 
>> ... but without the "Copyright-paperwork-exempt: yes" cookie 😕.  Should
>> I revert again?  (This time I will not act without explicit permission.)
>
> It's too late, since reverting a change doesn't remove it from Git
> history.
>
> I hope Xiyue Deng will assign the copyright, which will then cover
> this blunder.

I hope so too.

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 68375@debbugs.gnu.org,  manphiz@gmail.com
> Date: Thu, 11 Jan 2024 16:18:48 +0100
> 
> On Thu, 11 Jan 2024 16:51:39 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: eliz@gnu.org,  manphiz@gmail.com
> >> Date: Thu, 11 Jan 2024 14:44:35 +0100
> >>
> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> >> From: Xiyue Deng <manphiz@gmail.com>
> >> >> Date: Wed, 10 Jan 2024 14:56:23 -0800
> >> >>
> >> >> Please find the attached patches for a cumulation of documentation fixes
> >> >> for lispref up to chapter 19 that includes typos, formatting, etc.
> >> >> Please let me know if any changes need improvements and I'll adjust
> >> >> accordingly.
> >> >
> >> > Thanks.  See below.
> >> [...]
> >> >>    A string is a fixed sequence of characters.  It is a type of
> >> >> -sequence called a @dfn{array}, meaning that its length is fixed and
> >> >> +sequence called an @dfn{array}, meaning that its length is fixed and
> >> >
> >> > The "an" here is correct, since in a manual one sees "an array", which
> >> > is correct English.  So I didn't install this part.
> >>
> >> You misread the patch, it changes "a" to "an", which makes the text
> >> correct English.
> >
> > Oops.
> >
> >> I thought I'd save you some work by installing the patch myself,
> >> which I just did, but unfortunately to master instead of emacs-29
> >> (and also forgot to add the bug number).  Should I revert it and
> >> install to the release branch?  Sorry for the trouble.
> >
> > You could have simply cherry-picked it to emacs-29.
> 
> Is it possible to do that with VC?

No, not that I know of.

> I didn't find the term in the source code, only in
> admin/notes/git-workflow, which only shows the git command (and says
> to "add 'Backport:' to the commit string", which is another
> attention block I could well stumble over...).

If you cherry-pick with the -x option, gitmerge.el will recognize the
cherry-picks automatically, and there's no need for the "backport"
indication.

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 17:33:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 68375@debbugs.gnu.org,  manphiz@gmail.com
>> Date: Thu, 11 Jan 2024 16:18:48 +0100
[...]
>> >> I thought I'd save you some work by installing the patch myself,
>> >> which I just did, but unfortunately to master instead of emacs-29
>> >> (and also forgot to add the bug number).  Should I revert it and
>> >> install to the release branch?  Sorry for the trouble.
>> >
>> > You could have simply cherry-picked it to emacs-29.
>>
>> Is it possible to do that with VC?
>
> No, not that I know of.

Pity.

>> I didn't find the term in the source code, only in
>> admin/notes/git-workflow, which only shows the git command (and says
>> to "add 'Backport:' to the commit string", which is another
>> attention block I could well stumble over...).
>
> If you cherry-pick with the -x option, gitmerge.el will recognize the
> cherry-picks automatically, and there's no need for the "backport"
> indication.

Ah, ok.  But then shouldn't that directive be removed from the text,
since the example invocation has the -x option?  Anyway, hopefully I'll
be attentive enough in future to avoid needing to cherry-pick a commit
due to mistakenly installing a change to the wrong branch.

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 68375@debbugs.gnu.org,  manphiz@gmail.com
> Date: Thu, 11 Jan 2024 17:39:16 +0100
> 
> On Thu, 11 Jan 2024 17:33:17 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: 68375@debbugs.gnu.org,  manphiz@gmail.com
> >> Date: Thu, 11 Jan 2024 16:18:48 +0100
> [...]
> >> >> I thought I'd save you some work by installing the patch myself,
> >> >> which I just did, but unfortunately to master instead of emacs-29
> >> >> (and also forgot to add the bug number).  Should I revert it and
> >> >> install to the release branch?  Sorry for the trouble.
> >> >
> >> > You could have simply cherry-picked it to emacs-29.
> >>
> >> Is it possible to do that with VC?
> >
> > No, not that I know of.
> 
> Pity.
> 
> >> I didn't find the term in the source code, only in
> >> admin/notes/git-workflow, which only shows the git command (and says
> >> to "add 'Backport:' to the commit string", which is another
> >> attention block I could well stumble over...).
> >
> > If you cherry-pick with the -x option, gitmerge.el will recognize the
> > cherry-picks automatically, and there's no need for the "backport"
> > indication.
> 
> Ah, ok.  But then shouldn't that directive be removed from the text,
> since the example invocation has the -x option?

Maybe.  It does no harm, though.

bug#68375: 29.1; lispref documentation fixes

[Xiyue Deng]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Xiyue Deng <manphiz@gmail.com>
>> Date: Wed, 10 Jan 2024 14:56:23 -0800
>> 
>> Please find the attached patches for a cumulation of documentation fixes
>> for lispref up to chapter 19 that includes typos, formatting, etc.
>> Please let me know if any changes need improvements and I'll adjust
>> accordingly.
>
> Thanks.  See below.
>
>> --- a/doc/lispref/objects.texi
>> +++ b/doc/lispref/objects.texi
>> @@ -1573,7 +1573,7 @@ editing.
>>  (@pxref{Files}) so they can be edited, but some are used for other
>>  purposes.  Most buffers are also meant to be seen by the user, and
>>  therefore displayed, at some time, in a window (@pxref{Windows}).  But
>> -a buffer need not be displayed in any window.  Each buffer has a
>> +a buffer needs not be displayed in any window.  Each buffer has a
>
> This is not a typo: the wording here is correct English.  So I didn't
> install this part.
>

Indeed.  Please excuse my poor English.

>>    A string is a fixed sequence of characters.  It is a type of
>> -sequence called a @dfn{array}, meaning that its length is fixed and
>> +sequence called an @dfn{array}, meaning that its length is fixed and
>
> The "an" here is correct, since in a manual one sees "an array", which
> is correct English.  So I didn't install this part.

Thanks Stephen for the help, too!

>
>>  For information about other concatenation functions, see the
>> -description of @code{mapconcat} in @ref{Mapping Functions},
>> +descriptions of @code{mapconcat} in @ref{Mapping Functions},
>
> There's nothing wrong with using singular here, so I didn't install
> this part.
>
>> * doc/lispref/symbols.texi (Shorthands): Wrap `@pxref{Abbrevs}' in
>> parentheses.
>
> I installed this part.
>
>> >From 454ed28e302493d678d2306b908c9542a8491daa Mon Sep 17 00:00:00 2001
>> From: Xiyue Deng <manphiz@gmail.com>
>> Date: Tue, 2 Jan 2024 16:31:30 -0800
>> Subject: [PATCH 5/6] Fix count of no-op functions
>> 
>> It looks like there are actually three kinds of no-op functions.
>> 
>> * doc/lispref/functions.texi (Calling Functions): Fix count and
>> plural of no-op functions.
>
> I installed this part as well.
>
>> * doc/lispref/debugging.texi (Syntax Errors): Fix unmatched
>> parentheses.
>
> I didn't install this part, because there's nothing wrong with
> parentheses here.  Using @pxref as below:
>
>>    If the problem is not simply an imbalance of parentheses, a useful
>> -technique is to try @kbd{C-M-e} (@code{end-of-defun}, @pxref{Moving by
>> +technique is to try @kbd{C-M-e} (@code{end-of-defun}), @pxref{Moving by
>>  Defuns,,,emacs, The GNU Emacs Manual}) at the beginning of each defun,
>
> is perfectly correct.  So I didn't install this part.

Another example that late reading is not a good idea.  Sorry for the
noise.

>
> Please note that with this contribution we've exhausted the amount of
> changes we can accept from you without a copyright assignment.  Would
> you like to start the legal paperwork of assigning to the FSF the
> copyright for your future contributions?  If so, I will send you the
> form to fill and the instructions to email the filled form.

I'm already in the process and finished document.  I'm currently still
waiting for reply on how to handle employer exemption.  Hopefully I'll
hear back from assign@gnu.org soon.

>
> Thanks, I will now close this bug.

-- 
Xiyue Deng

bug#68375: 29.1; lispref documentation fixes

[Richard Stallman]

[[[ 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. ]]]

  >  therefore displayed, at some time, in a window (@pxref{Windows}).  But
  > -a buffer need not be displayed in any window.  Each buffer has a
  > +a buffer needs not be displayed in any window.  Each buffer has a

Actually, the old text is more correct English usage.
"Need" is a special case, and uses the old subjunctive mood
which is mostly obsolete in English.

  > -Somewhat odd, but predictable, behavior can occur for certain
  > +A somewhat odd, but predictable, behavior can occur for certain


The old text is correct.  In thise situation we are using "behavior"
as an uncountable mass noun.

Your other changes are correct.  Thanks.


-- 
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)

bug#68375: 29.1; lispref documentation fixes

[Xiyue Deng]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   >  therefore displayed, at some time, in a window (@pxref{Windows}).  But
>   > -a buffer need not be displayed in any window.  Each buffer has a
>   > +a buffer needs not be displayed in any window.  Each buffer has a
>
> Actually, the old text is more correct English usage.
> "Need" is a special case, and uses the old subjunctive mood
> which is mostly obsolete in English.
>
>   > -Somewhat odd, but predictable, behavior can occur for certain
>   > +A somewhat odd, but predictable, behavior can occur for certain
>
>
> The old text is correct.  In thise situation we are using "behavior"
> as an uncountable mass noun.
>
> Your other changes are correct.  Thanks.

Thanks for the detailed explanations!

-- 
Xiyue Deng

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Thu, 11 Jan 2024 22:56:42 -0500 Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   >  therefore displayed, at some time, in a window (@pxref{Windows}).  But
>   > -a buffer need not be displayed in any window.  Each buffer has a
>   > +a buffer needs not be displayed in any window.  Each buffer has a
>
> Actually, the old text is more correct English usage.
> "Need" is a special case, and uses the old subjunctive mood

In this sentence "need" is not in the subjunctive mood but is being used
as a modal verb, like "can", "must", etc.  What's special about "need"
in this usage is that it only occurs in so-called polarity contexts
(e.g. negative, interrogative), unlike the ordinary modal verbs (so
e.g. "A buffer need be displayed" is ungrammatical but "A buffer
can/must/may be displayed" is fine).  (An example of the subjunctive
mood is "be" in e.g. "This requires that a buffer not be displayed in
any window."  I can't off the top of my head think of an acceptable use
of "need" in the subjunctive, but perhaps there are such uses.)

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Richard Stallman]

[[[ 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. ]]]

  > In this sentence "need" is not in the subjunctive mood but is being used
  > as a modal verb, like "can", "must", etc.  What's special about "need"
  > in this usage is that it only occurs in so-called polarity contexts
  > (e.g. negative, interrogative), unlike the ordinary modal verbs (so
  > e.g. "A buffer need be displayed" is ungrammatical but "A buffer
  > can/must/may be displayed" is fine).

Is there a grammatical name for this sort of verb usage practice?

-- 
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)

bug#68375: 29.1; lispref documentation fixes

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Fri, 12 Jan 2024 22:54:48 -0500 Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > In this sentence "need" is not in the subjunctive mood but is being used
>   > as a modal verb, like "can", "must", etc.  What's special about "need"
>   > in this usage is that it only occurs in so-called polarity contexts
>   > (e.g. negative, interrogative), unlike the ordinary modal verbs (so
>   > e.g. "A buffer need be displayed" is ungrammatical but "A buffer
>   > can/must/may be displayed" is fine).
>
> Is there a grammatical name for this sort of verb usage practice?

If you mean the possibility of using an "ordinary" verb as a modal verb,
then I'm not aware of any term.  Maybe this is because this possibility
is so rare (at least in English; AFAIK the only other verb like "need"
is "dare").

If you mean the semantic restrictions on the use of "need" as a modal
verb, then AFAIK "polarity" is the most-widely used term (also in
compounds like "polarity-sensitive"), particularly within theoretical
linguistics but also in descriptive grammars like "The Cambridge Grammar
of the English Language".  (The phenomenon is much broader than the use
of "need", applying to the distributions of words like "any" and
"no(ne)", "ever" and "never" and so on.)

Steve Berman

bug#68375: 29.1; lispref documentation fixes

[Drew Adams]

>   > In this sentence "need" is not in the subjunctive mood but is being used
>   > as a modal verb, like "can", "must", etc.  What's special about "need"
>   > in this usage is that it only occurs in so-called polarity contexts
>   > (e.g. negative, interrogative), unlike the ordinary modal verbs (so
>   > e.g. "A buffer need be displayed" is ungrammatical but "A buffer
>   > can/must/may be displayed" is fine).
> 
> Is there a grammatical name for this sort of verb usage practice?

Dunno, but these might help:

https://english.stackexchange.com/a/128785/51214

https://english.stackexchange.com/a/281467/51214