all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* unreading a command key sequence
@ 2008-05-07  1:43 Lennart Borgman (gmail)
  2008-05-07  2:31 ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-07  1:43 UTC (permalink / raw)
  To: Emacs Devel

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-07  1:43 unreading a command key sequence Lennart Borgman (gmail)
@ 2008-05-07  2:31 ` Stefan Monnier
  2008-05-07  8:01   ` Lennart Borgman (gmail)
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2008-05-07  2:31 UTC (permalink / raw)
  To: Lennart Borgman (gmail); +Cc: Emacs Devel

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-07  2:31 ` Stefan Monnier
@ 2008-05-07  8:01   ` Lennart Borgman (gmail)
       [not found]     ` <jwvod7i883u.fsf-monnier+emacs@gnu.org>
  0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-07  8:01 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs Devel

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
       [not found]     ` <jwvod7i883u.fsf-monnier+emacs@gnu.org>
@ 2008-05-07 18:35       ` Lennart Borgman (gmail)
  2008-05-08  1:43         ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-07 18:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs Devel

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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-07 18:35       ` Lennart Borgman (gmail)
@ 2008-05-08  1:43         ` Stefan Monnier
  2008-05-08  8:04           ` Lennart Borgman (gmail)
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2008-05-08  1:43 UTC (permalink / raw)
  To: Lennart Borgman (gmail); +Cc: Emacs Devel

> 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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-08  1:43         ` Stefan Monnier
@ 2008-05-08  8:04           ` Lennart Borgman (gmail)
  2008-05-08 13:55             ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-08  8:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs Devel

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.




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-08  8:04           ` Lennart Borgman (gmail)
@ 2008-05-08 13:55             ` Stefan Monnier
  2008-05-08 21:00               ` Lennart Borgman (gmail)
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2008-05-08 13:55 UTC (permalink / raw)
  To: Lennart Borgman (gmail); +Cc: Emacs Devel

> 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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-08 13:55             ` Stefan Monnier
@ 2008-05-08 21:00               ` Lennart Borgman (gmail)
  2008-05-08 21:15                 ` David Kastrup
  0 siblings, 1 reply; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-08 21:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs Devel

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.




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-08 21:00               ` Lennart Borgman (gmail)
@ 2008-05-08 21:15                 ` David Kastrup
  2008-05-08 21:19                   ` Lennart Borgman (gmail)
  0 siblings, 1 reply; 10+ messages in thread
From: David Kastrup @ 2008-05-08 21:15 UTC (permalink / raw)
  To: Emacs Devel

"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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: unreading a command key sequence
  2008-05-08 21:15                 ` David Kastrup
@ 2008-05-08 21:19                   ` Lennart Borgman (gmail)
  0 siblings, 0 replies; 10+ messages in thread
From: Lennart Borgman (gmail) @ 2008-05-08 21:19 UTC (permalink / raw)
  To: David Kastrup; +Cc: Emacs Devel

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.




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-05-08 21:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-07  1:43 unreading a command key sequence Lennart Borgman (gmail)
2008-05-07  2:31 ` Stefan Monnier
2008-05-07  8:01   ` Lennart Borgman (gmail)
     [not found]     ` <jwvod7i883u.fsf-monnier+emacs@gnu.org>
2008-05-07 18:35       ` Lennart Borgman (gmail)
2008-05-08  1:43         ` Stefan Monnier
2008-05-08  8:04           ` Lennart Borgman (gmail)
2008-05-08 13:55             ` Stefan Monnier
2008-05-08 21:00               ` Lennart Borgman (gmail)
2008-05-08 21:15                 ` David Kastrup
2008-05-08 21:19                   ` Lennart Borgman (gmail)

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.