unreading a command key sequence

unreading a command key sequence

[Lennart Borgman (gmail)]

I just had a problem with unreading a command key sequence that lead to 
that Emacs looped. Looking into it I found that it is a bit non-trivial 
to unread a command key sequence. I am not sure I have got every thing 
correct but this is what I am using now

   ;; Unread the last command
   (setq last-command-char nil) ;; For viper
   (setq unread-command-events
         (listify-key-sequence (this-command-keys-vector)))

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")?

Re: unreading a command key sequence

[Stefan Monnier]

>   (setq unread-command-events
>         (listify-key-sequence (this-command-keys-vector)))

[ Ideally, you should not assume that unread-command-events was nil.  ]

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


        Stefan

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

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.

Re: unreading a command key sequence

[Stefan Monnier]

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

You seem to be thinking out loud.  I don't know what you mean by "such
things".


        Stefan

Re: unreading a command key sequence

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> 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.
> 
> You seem to be thinking out loud.  I don't know what you mean by "such
> things".

Sorry. "Such things" = when you want to prevent running this-command at 
the moment and instead want to change some things first, but still want 
the read key sequence to be used as input.

In my situation I want to change major mode first.

Re: unreading a command key sequence

[Stefan Monnier]

> Sorry. "Such things" = when you want to prevent running this-command at the
> moment and instead want to change some things first, but still want the read
> key sequence to be used as input.

That sounds hilarious to me: you say "such things" as if it's one of the
those things people do on a regular basis, and then you go on to
describe a very peculiar need.


        Stefan

Re: unreading a command key sequence

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> Sorry. "Such things" = when you want to prevent running this-command at the
>> moment and instead want to change some things first, but still want the read
>> key sequence to be used as input.
> 
> That sounds hilarious to me: you say "such things" as if it's one of the
> those things people do on a regular basis, and then you go on to
> describe a very peculiar need.

That made me a bit curious so I looked into Emacs sources to see what 
others used unread-command-events for. You are right, my need is 
uncommon. And those who need to use it can probably figure out how to 
use it.

Re: unreading a command key sequence

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

[...]

> That made me a bit curious so I looked into Emacs sources to see what
> others used unread-command-events for. You are right, my need is
> uncommon.

"You are right"?  Is this not considered inappropriate language on
emacs-devel?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: unreading a command key sequence

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
> [...]
> 
>> That made me a bit curious so I looked into Emacs sources to see what
>> others used unread-command-events for. You are right, my need is
>> uncommon.
> 
> "You are right"?  Is this not considered inappropriate language on
> emacs-devel?

My bad. Double error.