GNU bug report logs - #68375
29.1; lispref documentation fixes

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 68375 in the body.
You can then email your comments to 68375 AT debbugs.gnu.org in the normal way.

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

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

From: Xiyue Deng <manphiz <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; lispref documentation fixes
Date: Wed, 10 Jan 2024 14:56:23 -0800

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

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

[0001-Fix-typo-in-lispref-Buffer-Type-section.patch (text/x-diff, attachment)]

[0002-Fix-typo-in-lispref-String-Basics-section.patch (text/x-diff, attachment)]

[0003-Fix-typo-in-lispref-Creating-Strings-section.patch (text/x-diff, attachment)]

[0004-Wrap-pxref-of-Abbrevs-in-parentheses.patch (text/x-diff, attachment)]

[0005-Fix-count-of-no-op-functions.patch (text/x-diff, attachment)]

[0006-Fix-unmatched-parentheses.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Xiyue Deng <manphiz <at> gmail.com>
Cc: 68375-done <at> debbugs.gnu.org
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 12:46:34 +0200

> From: Xiyue Deng <manphiz <at> 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 <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 68375 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 14:44:35 +0100

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

>> From: Xiyue Deng <manphiz <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 68375 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 15:21:08 +0100

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

> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Xiyue Deng <manphiz <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 68375 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 15:32:10 +0100

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

> On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>>> From: Xiyue Deng <manphiz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 16:51:39 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: eliz <at> gnu.org,  manphiz <at> gmail.com
> Date: Thu, 11 Jan 2024 14:44:35 +0100
> 
> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Xiyue Deng <manphiz <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 16:56:13 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: eliz <at> gnu.org,  manphiz <at> gmail.com
> Date: Thu, 11 Jan 2024 15:32:10 +0100
> 
> On Thu, 11 Jan 2024 15:21:08 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> 
> > On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> >
> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >>>> From: Xiyue Deng <manphiz <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 16:18:48 +0100

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

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: eliz <at> gnu.org,  manphiz <at> gmail.com
>> Date: Thu, 11 Jan 2024 14:44:35 +0100
>>
>> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> >> From: Xiyue Deng <manphiz <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 16:18:59 +0100

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

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: eliz <at> gnu.org,  manphiz <at> gmail.com
>> Date: Thu, 11 Jan 2024 15:32:10 +0100
>> 
>> On Thu, 11 Jan 2024 15:21:08 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>> 
>> > On Thu, 11 Jan 2024 14:44:35 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>> >
>> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >>
>> >>>> From: Xiyue Deng <manphiz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 17:33:17 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 68375 <at> debbugs.gnu.org,  manphiz <at> gmail.com
> Date: Thu, 11 Jan 2024 16:18:48 +0100
> 
> On Thu, 11 Jan 2024 16:51:39 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Cc: eliz <at> gnu.org,  manphiz <at> gmail.com
> >> Date: Thu, 11 Jan 2024 14:44:35 +0100
> >>
> >> On Thu, 11 Jan 2024 12:46:34 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >> >> From: Xiyue Deng <manphiz <at> 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.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 17:39:16 +0100

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

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 68375 <at> debbugs.gnu.org,  manphiz <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 18:45:56 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 68375 <at> debbugs.gnu.org,  manphiz <at> gmail.com
> Date: Thu, 11 Jan 2024 17:39:16 +0100
> 
> On Thu, 11 Jan 2024 17:33:17 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Cc: 68375 <at> debbugs.gnu.org,  manphiz <at> 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.

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

From: Xiyue Deng <manphiz <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 68375-done <at> debbugs.gnu.org
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 08:46:57 -0800

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

>> From: Xiyue Deng <manphiz <at> 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 <at> 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 <at> gnu.org soon.

>
> Thanks, I will now close this bug.

-- 
Xiyue Deng

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

From: Richard Stallman <rms <at> gnu.org>
To: Xiyue Deng <manphiz <at> gmail.com>
Cc: 68375 <at> debbugs.gnu.org
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 22:56:42 -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. ]]]

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

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

From: Xiyue Deng <manphiz <at> gmail.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Thu, 11 Jan 2024 21:44:20 -0800

Richard Stallman <rms <at> 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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org, Xiyue Deng <manphiz <at> gmail.com>
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Fri, 12 Jan 2024 10:46:08 +0100

On Thu, 11 Jan 2024 22:56:42 -0500 Richard Stallman <rms <at> 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

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

From: Richard Stallman <rms <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Fri, 12 Jan 2024 22:54:48 -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. ]]]

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

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Richard Stallman <rms <at> gnu.org>
Cc: 68375 <at> debbugs.gnu.org, manphiz <at> gmail.com
Subject: Re: bug#68375: 29.1; lispref documentation fixes
Date: Sat, 13 Jan 2024 17:21:14 +0100

On Fri, 12 Jan 2024 22:54:48 -0500 Richard Stallman <rms <at> 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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: "rms <at> gnu.org" <rms <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>
Cc: "68375 <at> debbugs.gnu.org" <68375 <at> debbugs.gnu.org>,
 "manphiz <at> gmail.com" <manphiz <at> gmail.com>
Subject: RE: [External] : bug#68375: 29.1; lispref documentation fixes
Date: Sat, 13 Jan 2024 19:07:04 +0000

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

Previous Next

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