[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Severe lossage from unread-command-events
From: |
David Kastrup |
Subject: |
Re: Severe lossage from unread-command-events |
Date: |
Thu, 06 Aug 2015 22:00:10 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
David Kastrup <address@hidden> writes:
> David Kastrup <address@hidden> writes:
>
>> Well, according to how I read the variable description of
>> unread-command-events, some are bounced back there from input which has
>> already been recorded. The description reads:
>>
>> Documentation:
>> List of events to be read as the command input.
>> These events are processed first, before actual keyboard input.
>> 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.
>>
>> My test programs used (t . EVENT) after just using EVENT did not do the
>> trick either.
>
> Uh oh. This is bad news for macro recording of list events.
>
> Defining kbd macro...
> Auto-saving...done
> <t> is undefined
>
> and the "<t> is undefined" message comes with an abort of macro
> recording. Quite the nuisance. So I'll remove the t thing again and
> will see how I fare then.
>
> Now obviously if my events appear first in unread-command-events, they
> cannot already have been added to this-command-keys, but at least list
> events apparently must not be added in the (t . EVENT) form or
> _something_ will attempt a lookup and fail.
>
> Since the message appears only _once_, it would appear that the problem
> stops occuring the moment macro recording by C-x ( has stopped.
>
> What a can of worms.
Looks like I can (and must) leave off the (cons t ...) for my use case.
I haven't seen any bad effects from doing so: events are looked up in
keymaps and recorded just fine so far. I don't know what the
implications of the t thing are. But other than that, things do look
good so far.
--
David Kastrup
- Re: Severe lossage from unread-command-events, (continued)
- Re: Severe lossage from unread-command-events, Stefan Monnier, 2015/08/07
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/07
- Re: Severe lossage from unread-command-events, raman, 2015/08/08
- Re: Severe lossage from unread-command-events, Eli Zaretskii, 2015/08/07
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/06
- Re: Severe lossage from unread-command-events, Eli Zaretskii, 2015/08/06
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/06
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/06
- Re: Severe lossage from unread-command-events,
David Kastrup <=
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/10
- Re: Severe lossage from unread-command-events, Eli Zaretskii, 2015/08/10
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/10
- Re: Severe lossage from unread-command-events, Eli Zaretskii, 2015/08/10
- Re: Severe lossage from unread-command-events, David Kastrup, 2015/08/10