[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Kifer
Subject: bug#13709: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 02:17:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 02/25/2013 04:35 PM, Stefan Monnier wrote:
The function `follow_key` has been changed by the problematic commit.
Formerly severall keymaps have been passed in an array. Each keymap
has been checked in turn for a binding. One of the keymaps is
`evil-esc-map`. If this keymap is checked no binding is found. So the
next keymap is checked an it may contain a binding for M-x so this
binding is used.
Oh, I think I see what's going on.  So the Evil code (and Viper, since
it seems to use the same gymnastics) really relies on some pretty nasty
detail of the level at which the M-x => ESC x rewriting took place,
which was subtly changed.

That could also explain why `f1 f M-x' already didn't find the binding
in the old code.

Yes, Viper uses a similar mechanism (in the sense of having a special map just for the ESC key).

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

At the time there was no input-decode-map - I am pretty sure.
Viper uses a trick that relies on unread-command-events and emulation-mode-map-alist
to  distinguish between ESC key and ESC sequences on dumb terminals.
(in viper-envelop-ESC-key() in viper-cmd.el).

I must admit that the intricacies of the code are rusty in my head  now, so it is hard for me to evaluate the consequences of the change. It might  simplify things  or it might break them.


       --- michael

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]