Re: Severe lossage from unread-command-events

[David Kastrup <dak@gnu.org>]

David Kastrup <dak@gnu.org> writes:

> David Kastrup <dak@gnu.org> 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