GNU bug report logs - #13793
24.3.50; M-x broken in viper and X

Previous Next

Package: emacs;

Reported by: Frank Fischer <frank-fischer <at> shadow-soft.de>

Date: Sat, 23 Feb 2013 18:51:02 UTC

Severity: important

Merged with 13709, 13739

Found in version 24.3.50

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Frank Fischer <frank-fischer <at> shadow-soft.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org, Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 21:17:14 +0100
On 02/26, Stefan Monnier wrote:
> I think what we really care about is to detect "called from
> read-key-sequence".  How 'bout:
> 
> (defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
> (define-key input-decode-map
>   [?\e] `(menu-item "" ,evil-normal-esc-map
>           :filter ,(λ (map)
>                      (if (and (not evil-inhibit-escape)
>                               (equal (this-single-command-keys) [?\e])
>                               (sit-for 0.1))
>                          [escape] map))))
> 
> So the special ESC=>escape mapping only takes place if the whole
> last key-sequence so far is just [?\e], i.e. either we're still in
> read-key-sequence, or the last read-key-sequence only read [?\e], which
> should ideally never happen because it should have been mapped to [escape].

Sounds good to me. At least, I can't think of a problematic situation,
currently. Let's how it works in practise.

Thank you for your efforts. I would never have thought of this
solution on my own.

Best regards,
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.