unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Merging scratch/substitute-command-keys to master
Date: Sat, 17 Oct 2020 23:35:31 +0000	[thread overview]
Message-ID: <CADwFkmnM8yMLf-UFZjuFqtkkhs+R8G4Ubo+epsS8gZtk+Lwx8g@mail.gmail.com> (raw)
In-Reply-To: <jwvy2k4oomf.fsf-monnier+emacs@gnu.org>

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

> I don't have a clean baseline against which to run such tests, but I can
> confirm that the speed is comparable

Thanks, that information is very useful.

> See comments below.  Other than those details, LGTM,
[...]
> We generally do either of those or yet something else (e.g. rebase,
> with or without cleaning up the history).
> I like to just merge, personally.

Thank you kindly for the review.

I've fixed all your comments unless indicated otherwise below.  I'm
currently working on cleaning up the history of the branch and will push
a new version of the branch, that I then plan to merge to the master
branch.

>> +;; (defun describe-keymap-or-char-table
> [...]
>> +;;       (let* ((val (aref keymap idx))
>
> `aref` will signal an error when applied to a keymap.
> So your `keymap` variable doesn't hold a keymap, and so your function
> name is misleading.

Right.  I probably picked up this terminological confusion from
describe_vector, where the documentation says, a bit confusingly, that
"KEYMAP_P is 1 if vector is known to be a keymap".  But of course a
vector is never a keymap, at least not according to `keymapp'.  So the
argument here should better be called `vector' (as is the case in
the describe_vector function on which this is based).

> Also this function should probably have a "help--" prefix because it
> should stay as an internal detail.

See the discussion on this name below.

>> +    {
>> +      msg = build_unibyte_string("Key translations");
>         ^                         ^^
>     Lisp_Object                   SPC
>
> Your compiler will be just as happy with many such "small scope" vars as
> with your larger scope var.
>
> Also, you might want to use `AUTO_STRING` here.

(I fixed the first part here.)

I tried using AUTO_STRING at first, but these strings are passed to
Qdescribe_map_tree so that leads to segfault if there is a GC.
While investigating that, I learned that AUTO_STRINGs are allocated on the
stack (I guess without the proper reference counters?) and shouldn't be
passed to Lisp code.

>> @@ -2793,8 +2815,11 @@ DEFUN ("describe-buffer-bindings", Fdescribe_buffer_bindings, Sdescribe_buffer_b
>
> BTW, I see that `describe-buffer-bindings` is a natural next candidate
> for ELispification ;-)

Indeed!

>> +DEFUN ("describe-keymap-or-char-table", Fdescribe_keymap_or_char_table,
> [...]
>> +  CHECK_VECTOR_OR_CHAR_TABLE (vector);
>
> The code says VECTOR_OR_CHAR_TABLE, so your function's name might want
> to do the same.  Or maybe call it `describe-vector` since it seems to be
> a thin wrapper around that function.

The problem is that there is already a `describe-vector' with a
different calling convention.  So perhaps we should just go with
`describe-vector-or-char-table' (clunky as it may be) if no one has a
better proposal.  Or maybe `help--describe-vector' is better?  Or the
iniquitous `help--describe-vector-or-char-table'?

Thanks again for reviewing.



  reply	other threads:[~2020-10-17 23:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 14:03 Merging scratch/substitute-command-keys to master Stefan Kangas
2020-10-17 15:05 ` Eli Zaretskii
2020-10-17 16:19 ` Stefan Monnier
2020-10-17 23:35   ` Stefan Kangas [this message]
2020-10-18  4:09     ` Stefan Monnier
2020-10-18 11:42       ` Stefan Kangas
2020-10-18 16:11     ` Stefan Kangas
2020-10-17 17:22 ` Drew Adams
2020-10-17 17:46   ` Stefan Kangas

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=CADwFkmnM8yMLf-UFZjuFqtkkhs+R8G4Ubo+epsS8gZtk+Lwx8g@mail.gmail.com \
    --to=stefan@marxist.se \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).