emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master 5b5f441: read_key_sequence: correct the handlin


From: Stefan Monnier
Subject: Re: [Emacs-diffs] master 5b5f441: read_key_sequence: correct the handling of raw_keybuf in recursive calls
Date: Wed, 22 Nov 2017 15:29:00 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> Right: the middle one corresponds to `read-key-sequence` which can be
>> called from "anywhere" (i.e. Elisp).
> That is surely not the problem.  The problem would be if something
> aborted a read_key_sequence, and somehow started another one without
> going via command_loop_1.

I was thinking more of:

  (progn (catch 'foo (read-key-sequence ...))
    ...
    (this-single-command-raw-keys))

where a timer throws `foo` during read-key-sequence.
Since this-single-command-raw-keys uses the raw_keybuf, it ends up
dereferencing the "stale" pointer to the var that was local in
read_key_sequence.

>> > You have a point, here.  Perhaps it would be better to get storage from
>> > the Emacs heap rather than using the stack.
>> I like using the stack, here, actually.
> I thought about that.

No, I mean, I like the fact that your code uses the stack.

>> Maybe another option is to make raw_keybuf local to read_key_sequence,
>> and to *copy* it into the global raw_keybuf_buffer just before exiting.
> That's quite close to what I've done.  The difficulty is in getting a
> pointer to that local buffer for use by the menu handling code.

Hmm... could you show me that menu handling code you're referring to?
The only user I can see of raw_keybuf (outside of local uses within
read_key_sequence) is this-single-command-raw-keys, so maybe I'm
missing something.

>> PS: Of course, even better would be to provide another way to get what
>> `this-single-command-raw-keys` returns, so we don't need to use a global
>> variable for it.  E.g. have `read-key-sequence` return both the key
>> sequence and the raw key sequence.  But we'd still have to support
>> `this-single-command-raw-keys` for the foreseeable future anyway.
> I don't think that idea would fly.  Most uses of `read-key-sequence'
> aren't going to be interested in the raw events.

[ This is really a side-discussion about a better solution for the
  long-term, but we need to solve the current problem regardless.  ]
I was thinking of adding a new function read-raw-key-sequence which
returns both the normal and the raw key sequences, with the hope that
all users of this-single-command-raw-keys could eventually be changed to
make use of that new function instead.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]