differentiating real and fake command events

differentiating real and fake command events

[Psionic K]

I'm adding macro playback support to dslide.  My first pass is workable but
not literally fool proof.

The implementation sets `unread-command-events' using a recursive timer
function.  This was the first implementation I found that wouldn't eat the
events, as `sit-for' etc enjoy doing.  I would prefer a blocking
implementation to prevent any input from my playback to help save users
from screwing up.

If no blocking approach is feasible, I need ways to decide if the user
pressed a key.  I need to block this key if possible, but at least with
detection I can begin some recovery strategy.

Re: differentiating real and fake command events

[Stefan Monnier via Users list for the GNU Emacs text editor]

> I'm adding macro playback support to dslide.  My first pass is workable but
> not literally fool proof.

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


        Stefan

Re: differentiating real and fake command events

[Psionic K]

> 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.

Re: differentiating real and fake command events

[Stefan Monnier via Users list for the GNU Emacs text editor]

> 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.
[...]

Hmm...

> 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.

Yeah, I think the easiest path is to tell the user "don't touch
anything".

One trick that you could try is to use `special-event-map`.  AFAICT from
reading the code of `read_char`, this map is consulted for "real" events
but not for events coming from `unread-command-events`, so maybe
something like:

    (define-key special-event-map [t] #'my-consume-real-input)
    (defvar my-stashed-real-input nil)
    (defun my-consume-real-input ()
      (interactive)
      (push last-input-event my-stashed-real-input))

Hmm... it looks like the "default binding" feature (i.e. the [t] above)
is not used when consulting that `special-event-map`, so that won't work
(you'd need a "magic" keymap which has a binding for all possible events).

Maybe you should log a feature request with `M-x report-emacs-bug`.


        Stefan

Re: differentiating real and fake command events

[mbork]

On 2024-12-15, at 15:00, Psionic K <psionik@positron.solutions> wrote:

>> 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.

Are you aware of the demo-it package
(https://github.com/howardabrams/demo-it)?  Also, I had a similar idea
(to use keyboard macros for demo-it "presentations"), see here:
https://mbork.pl/2017-08-07_demo-it_recording#.

BTW, I saw some discussion about dslide on R*ddit, it looks very
promising!  I might need something for a presentation soon, I am /very/
tempted to use dslide for that!

Just my 2 cents...

-- 
Marcin Borkowski
https://mbork.pl
https://crimsonelevendelightpetrichor.net/