GNU bug report logs - #73584
29.3; read-key

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73584 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 Emacs-hacker2023 <at> jovi.net
Subject: Re: bug#73584: 29.3; read-key
Date: Thu, 03 Oct 2024 11:43:25 -0400

> The OP shot himself in the foot by invoking by hand a low-level
> function with a wrong argument.  Interactive functions and high-level
> APIs must check their arguments right away, but low-level functions
> like this one do not.

I think the "bug" is indeed not in the fact that we check too late for
a string.  I guess we could say that any code which temporarily rebinds
the global map should be super-extra careful never to signal an error,
and prevent itself from being Edebugged etc... but it would be
preferable for the debuggers to "handle it".

> Stefan Monnier, do we have a good way of doing that in cases like
> this?  Perhaps the debugger should define some minimal key bindings
> when it starts or something?

The debuggers already do a fair bit of "setup" to try and isolate the
state of the debugger from the state of the debugged code.

If we got rid of `current-global-map` and `use-global-map` (and instead
just tied the ELisp `global-map` to C's `current_global_map`, so we
could (re) define those two functions in ELisp), then `read-key` could
let-bind `global-map` and the debuggers could also let-bind it (back) to
the value in `default-toplevel-value`.

Short of doing that we could have a new var `normal-global-map` which
would be initialized to the value of `global-map` and then make the
debuggers install that map with `set-global-map` while they're active.

More generally, the debuggers should (behave as if they're) run
in their own thread so they're not affected by the dynamic-bindings of
the code they're debugging.

>> I meant to ask if we have something similar to `cl-check-type' that does
>> not come from cl-lib.el.  I'm asking that precisely because we can't use
>> cl-lib in subr.el.
> Sorry, my misunderstanding.

A think a better course of action for this specific sub-problem is to
arrange for `read-keys` to be able to use `cl-check-type` (instead of
re-inventing it).

In general, I think it would be beneficial to split `subr.el` into two
files: one that is still loaded just as early and another that's loaded
a bit later so it can use `cl-lib` macros.
In the mean time, we can often get a similar result by moving the code
to `simple.el`.

There can be other ways to solve this bootstrap problem.  Such as
arranging for `subr.el` to load `cl-lib` in a slightly more careful way
than `eval-when-compile`: it would load it when the file is being
compiled (just like `eval-when-compile`) or it would schedule `cl-lib`
for "near future" loading (as soon as enough other files have been
loaded that `cl-lib` can be loaded).  As long as `cl-lib` is loaded
before `read-keys` is called, that would be sufficient.


        Stefan

Previous Next

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