[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [elpa] externals/cape 45fe322c99: cape-company-to-capf: Remove (t .
From: |
Stefan Monnier |
Subject: |
Re: [elpa] externals/cape 45fe322c99: cape-company-to-capf: Remove (t . cape--done) from unread-command-events (Fix #23) |
Date: |
Sat, 15 Jan 2022 10:44:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> + ;; XXX NOTE: For some reason Emacs sometimes converts
> + ;; cape--done to (t . cape--done).
`unread-command-events` is pretty tricky/nasty to get right.
So I'm not sure if what you see is normal or is a bug.
This said, the docstring says:
Events read from this list are not normally added to ‘this-command-keys’,
as they will already have been added once as they were read for the first
time.
An element of the form (t . EVENT) forces EVENT to be added to that list.
An element of the form (no-record . EVENT) means process EVENT, but do not
record it in the keyboard macros, recent-keys, and the dribble file.
So it sounds like (t . cape--done) would be an error, given that I can't
think of a good reason why we'd want to add the pseudo-event `cape--done`
to `this-command-keys`.
So, if you can find a recipe to reproduce the problem, it would be good
to report it as a bug (see how it's used in async-style code with
a `sit-for` loop, I expect it'll be nasty to reproduce and even worse
to debug).
Stefan
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [elpa] externals/cape 45fe322c99: cape-company-to-capf: Remove (t . cape--done) from unread-command-events (Fix #23),
Stefan Monnier <=