unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robin Tarsiger <rtt@dasyatidae.com>
To: Emacs-Devel List <emacs-devel@gnu.org>
Subject: Why does help-fns--first-release not key on `' delimiters?
Date: Thu, 6 Jan 2022 10:58:35 -0600	[thread overview]
Message-ID: <bb3ab283-0778-ccc2-7e05-fa146e1fcd56@dasyatidae.com> (raw)

So, for some context first:

Recently, I went to check when the tagged record type had been added to
Emacs, and typed C-h f record, only to see:

 > (record TYPE &rest SLOTS)
 >
 >   Probably introduced at or before Emacs version 1.9.

This didn't seem right at all, and unfortunately, the NEWS.1-17 line it
linked to was part of the following paragraph:

 > ** write-kbd-macro and append-kbd-macro are used to save
 >  a kbd macro definition in a file (as Lisp code to
 >  redefine the macro when the file is loaded).
 >  These commands differ in that write-kbd-macro
 >  discards the previous contents of the file.
 >  If given a prefix argument, both commands
 >  record the keys which invoke the macro as well as the
    ^^^^^^
 >  macro's definition.

This is a very silly result. (For the, er, record, the _actual_ NEWS
entry for record types is at NEWS.26:1507, under the section for Lisp
changes in Emacs 26.1.)

Looking at the function help-fns--first-release that generates this
text, it looks like it just searches for the symbol name. However, it
seems to be conventional in these NEWS files for important symbols to
be surrounded by `' pseudo-quotes, just like in e.g. elisp docstrings.

Is there a reason help-fns--first-release doesn't already expect these?
Presumably the matching is best-effort to begin with, and this seems
like it could eliminate a lot of false positives.

It's not costless, of course; one counterexample I saw is that Emacs 17's
section on renaming `dot' to `point' in various symbols doesn't use those
delimiters around each of the indvidual names:

 > ** `dot' renamed `point'.
 >
 > The word `dot' has been replaced with `point' in all
 > function and variable names, including:
 >
 >   point, point-min, point-max,
 >   point-marker, point-min-marker, point-max-marker,
 >   window-point, set-window-point,
 >   point-to-register, register-to-point,
 >   exchange-point-and-mark.
 >
 > The old names are still supported, for now.

but at first glance this seems like an acceptable tradeoff.

Thoughts?

-RTT



             reply	other threads:[~2022-01-06 16:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 16:58 Robin Tarsiger [this message]
2022-01-09 23:42 ` Why does help-fns--first-release not key on `' delimiters? Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb3ab283-0778-ccc2-7e05-fa146e1fcd56@dasyatidae.com \
    --to=rtt@dasyatidae.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).