GNU bug report logs -
#13793
24.3.50; M-x broken in viper and X
Previous Next
Full log
Message #22 received at 13793 <at> debbugs.gnu.org (full text, mbox):
On 02/25, Stefan Monnier wrote:
> > Anyhow, the real problem is to "multiplex" the (kbd "ESC") event in
> > the terminal. Any solution that sends 'escape instead of (kbd "ESC")
> > if another event arrives within a short period should solve the
> > problem.
>
> Now my question is: why do it with a minor-mode map rather than with
> an input-decode-map (which would also save you from having to rely on
> unread-command-events)? Oh, yes, of course, that input-decode-map
> binding would collide with the escape-sequence remappings.
>
> How 'bout something like:
>
> (defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
> (define-key input-decode-map
> [?\e] `(menu-item "" ,evil-normal-esc-map
> :filter ,(lambda (map)
> (if (sit-for evail-esc-delay) [escape] map))))
This is a really clever solution, thank you a lot. It looks much
better than the current one. The Evil code is naturally "inspired" by
viper's code, so the reasons for its current form are hidden in the
shadows of history ;)
I will build something like this into Evil, then we will see if it
breaks something.
>
> [ Modulo some dance à la evil-esc-mode to add/remove this binding so
> that code that adds escape sequences to this map never bumps into the
> [escape] mapping. ]
Maybe one question, because I'm not too familiar with translation
keymaps. What do you think is the best solution to this
add-escape-sequences-to-input-decode-map-problem? The only possibility
that comes into my mind would be to advice `define-key` so that
`evil-normal-esc-map` is temporarily put back into `input-decode-map`.
Is there a better way than using such an advice?
Once again, thank you a lot!
Frank
This bug report was last modified 8 years and 36 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.