bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

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