Re: unreading a command key sequence

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> > > > (setq unread-command-events
> > > > (listify-key-sequence (this-command-keys-vector)))
> > > [ Ideally, you should not assume that unread-command-events was nil.  ]
>
> > No, but I was unsure how to add to the list ...
>
>
> > > > The missing bit that lead to the looping was setting last-command-char
> > > > to nil.
> > > > Maybe something like this could be included in the manual in
> > > > (info "(elisp) Event Input Misc")?
> > > I'd rather fix whichever code is responsible for the inf-loop.
> > > Can you provide a recipe to reproduce the problem?
>
> > Maybe I can provide a simple recipe, but I think there probably is nothing
> > to fix.  I believe the looping I saw was because of the way Viper is
> > written.  When you do something like d, y, c etc then `last-command-char'
> > will be used. (Of course other commands may do similar things, there is
> > nothing wrong with it AFAICS.)
>
> An inf-loop is a bug.  And I have a hard time imagining why
> (setq last-command-char nil) would be The Right Fix(TM) (it might be an
> OK fix if you don't have access to the rest of the code, tho).


Thanks, you are right, of course.

I do this in pre-command-hook and I just did forget that this-command 
still will be carried out (and that was what I wanted to prevent). I 
think this is what I should do instead:

  (setq this-command 'tunnel-last-command)
  (setq unread-command-events
        (append unread-command-events
                (listify-key-sequence
                 (this-command-keys-vector))
                nil))
  (defun tunnel-last-command ()
    "Set `this-command' to `last-command'."
    (interactive)
    (setq this-command last-command))

This works for in the tests I have made (including some with Viper undo 
involved). If this is the way to do such things in pre-command-hook then 
this might be worth documenting.