Re: differentiating real and fake command events

[Psionic K <psionik@positron.solutions>]

> I don't understand enough of the context.  Could you explain in what way
> you need something different from `execute-kbd-macro`?

I'm implementing "live" demo features for dslide.  It relies on
playing back macros at human speed.  The goal is to emulate the
results of using Emacs by hand, to appear as a live demonstration, but
with reproducibility.  This frees the presenter from having to think
and type at the same time while still conveying the organic experience
to those watching.  Keyboard macros executed via `execute-kbd-macro'
replay input at inhuman speed and lose the similarity of feedback that
enables the audience to relate what they see with what they normally
do.

The first issue I ran into was simply getting `unread-command-events'
to result in input.  For my first pass solution, I accomplished this
with a function that calls itself recursively via `run-at-time'.  I
may try threads.

The recursive function currently also compares `last-input-event' to
detect incoherence caused by extra user inputs (and possibly others?).
If the last key pushed into `unread-command-events' doesn't match, it
messages and aborts.  This approach is invalid for replaying sequences
that will result in extra events.

Rather than detect potentially corrupting extra inputs, I would block
the user's inputs and allow only the synthetic events to succeed.  It
is unnatural to block the user from typing inputs while also pushing
synthetic input into `unread-command-events'.  One idea I had was to
activate a keymap in between pushing events.  However, I think this
would depend on the command loop evaluation order and wind up being
fragile.

I expect there are many paths that appear viable but only some that
are truly good and will remain so for at least a few years.