GNU bug report logs - #13709
24.3.50; Evil breaks Meta on r111745

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13709 in the body.
You can then email your comments to 13709 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Sturm <sebastian.sturm <at> uni-leipzig.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Evil breaks Meta on r111745
Date: Wed, 13 Feb 2013 21:16:48 +0100

With evil mode activated (using evil-20130212.906), the Meta key is not
recognized anymore (i.e., pressing M-q displays the error message "M-q
is undefined", even though C-h k M-q shows that M-q is bound to
fill-paragraph). With r111730, everything works as expected.


In GNU Emacs 24.3.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
of 2013-02-12 on bob.porkrind.org
Bzr revision: 111745 rgm <at> gnu.org-20130212073854-k9p1upkgzw35nonq
Windowing system distributor `Apple', version 10.3.1187
Configured using:
`configure --host=x86_64-apple-darwin --build=i686-apple-darwin
--with-ns'

Important settings:
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  rainbow-mode: t
  rainbow-delimiters-mode: t
  paredit-mode: t
  helm-mode: t
  helm-match-plugin-mode: t
  evil-mode: t
  evil-local-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  autopair-global-mode: t
  autopair-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  eldoc-mode: t
  icomplete-mode: t
  volatile-highlights-mode: t
  global-hl-line-mode: t
  show-paren-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  savehist-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  prelude-mode: t
  prelude-global-mode: t
  which-function-mode: t
  tooltip-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
k k M-q C-x RET b u g <backspace> <backspace> <backspace> 
f i l e - b <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> b u g l ; <backspace> <backspace> 
- r e p <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> r e p o r t - C-n 
C-n C-n C-n C-n C-n <return>

Recent messages:
Loading /Users/sebastian/.emacs.d/personal/custom.el (source)...
Loading scroll-all...done
Loading /Users/sebastian/.emacs.d/personal/custom.el (source)...done
Loading /Users/sebastian/.emacs.d/personal/my-modeline.el (source)...done
Loading /Users/sebastian/.emacs.d/personal/personal.el (source)...
Helm completion enabled
Loading /Users/sebastian/.emacs.d/personal/personal.el (source)...done
Prelude is ready to do thy bidding, Master sebastian!
For information about GNU Emacs and the GNU system, type C-h C-a.
Prelude tip: Visit WikEmacs at http://wikemacs.org to find out even more about Emacs.

Load-path shadows:
/Users/sebastian/.emacs.d/elpa/magit-20130206.1334/.dir-locals hides /Users/sebastian/.emacs.d/elpa/sunrise-commander-20130107.37/.dir-locals
/Users/sebastian/.emacs.d/elpa/python-20130212.1510/python hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/progmodes/python
/Users/sebastian/.emacs.d/elpa/org-20130211/org hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org
/Users/sebastian/.emacs.d/elpa/org-20130211/org-xoxo hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-xoxo
/Users/sebastian/.emacs.d/elpa/org-20130211/org-wl hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-wl
/Users/sebastian/.emacs.d/elpa/org-20130211/org-w3m hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-w3m
/Users/sebastian/.emacs.d/elpa/org-20130211/org-vm hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-vm
/Users/sebastian/.emacs.d/elpa/org-20130211/org-version hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-version
/Users/sebastian/.emacs.d/elpa/org-20130211/org-timer hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-timer
/Users/sebastian/.emacs.d/elpa/org-20130211/org-taskjuggler hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-taskjuggler
/Users/sebastian/.emacs.d/elpa/org-20130211/org-table hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-table
/Users/sebastian/.emacs.d/elpa/org-20130211/org-src hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-src
/Users/sebastian/.emacs.d/elpa/org-20130211/org-special-blocks hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-special-blocks
/Users/sebastian/.emacs.d/elpa/org-20130211/org-rmail hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-rmail
/Users/sebastian/.emacs.d/elpa/org-20130211/org-remember hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-remember
/Users/sebastian/.emacs.d/elpa/org-20130211/org-publish hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-publish
/Users/sebastian/.emacs.d/elpa/org-20130211/org-protocol hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-protocol
/Users/sebastian/.emacs.d/elpa/org-20130211/org-plot hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-plot
/Users/sebastian/.emacs.d/elpa/org-20130211/org-pcomplete hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-pcomplete
/Users/sebastian/.emacs.d/elpa/org-20130211/org-odt hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-odt
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mouse hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mouse
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mobile hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mobile
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mks hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mks
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mhe hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mhe
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mew hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mew
/Users/sebastian/.emacs.d/elpa/org-20130211/org-macs hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-macs
/Users/sebastian/.emacs.d/elpa/org-20130211/org-mac-message hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-mac-message
/Users/sebastian/.emacs.d/elpa/org-20130211/org-lparse hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-lparse
/Users/sebastian/.emacs.d/elpa/org-20130211/org-loaddefs hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-loaddefs
/Users/sebastian/.emacs.d/elpa/org-20130211/org-list hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-list
/Users/sebastian/.emacs.d/elpa/org-20130211/org-latex hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-latex
/Users/sebastian/.emacs.d/elpa/org-20130211/org-jsinfo hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-jsinfo
/Users/sebastian/.emacs.d/elpa/org-20130211/org-irc hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-irc
/Users/sebastian/.emacs.d/elpa/org-20130211/org-install hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-install
/Users/sebastian/.emacs.d/elpa/org-20130211/org-inlinetask hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-inlinetask
/Users/sebastian/.emacs.d/elpa/org-20130211/org-info hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-info
/Users/sebastian/.emacs.d/elpa/org-20130211/org-indent hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-indent
/Users/sebastian/.emacs.d/elpa/org-20130211/org-id hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-id
/Users/sebastian/.emacs.d/elpa/org-20130211/org-icalendar hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-icalendar
/Users/sebastian/.emacs.d/elpa/org-20130211/org-html hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-html
/Users/sebastian/.emacs.d/elpa/org-20130211/org-habit hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-habit
/Users/sebastian/.emacs.d/elpa/org-20130211/org-gnus hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-gnus
/Users/sebastian/.emacs.d/elpa/org-20130211/org-freemind hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-freemind
/Users/sebastian/.emacs.d/elpa/org-20130211/org-footnote hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-footnote
/Users/sebastian/.emacs.d/elpa/org-20130211/org-feed hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-feed
/Users/sebastian/.emacs.d/elpa/org-20130211/org-faces hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-faces
/Users/sebastian/.emacs.d/elpa/org-20130211/org-exp hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-exp
/Users/sebastian/.emacs.d/elpa/org-20130211/org-exp-blocks hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-exp-blocks
/Users/sebastian/.emacs.d/elpa/org-20130211/org-eshell hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-eshell
/Users/sebastian/.emacs.d/elpa/org-20130211/org-entities hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-entities
/Users/sebastian/.emacs.d/elpa/org-20130211/org-element hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-element
/Users/sebastian/.emacs.d/elpa/org-20130211/org-docview hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-docview
/Users/sebastian/.emacs.d/elpa/org-20130211/org-docbook hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-docbook
/Users/sebastian/.emacs.d/elpa/org-20130211/org-datetree hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-datetree
/Users/sebastian/.emacs.d/elpa/org-20130211/org-ctags hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-ctags
/Users/sebastian/.emacs.d/elpa/org-20130211/org-crypt hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-crypt
/Users/sebastian/.emacs.d/elpa/org-20130211/org-compat hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-compat
/Users/sebastian/.emacs.d/elpa/org-20130211/org-colview hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-colview
/Users/sebastian/.emacs.d/elpa/org-20130211/org-clock hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-clock
/Users/sebastian/.emacs.d/elpa/org-20130211/org-capture hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-capture
/Users/sebastian/.emacs.d/elpa/org-20130211/org-bibtex hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-bibtex
/Users/sebastian/.emacs.d/elpa/org-20130211/org-beamer hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-beamer
/Users/sebastian/.emacs.d/elpa/org-20130211/org-bbdb hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-bbdb
/Users/sebastian/.emacs.d/elpa/org-20130211/org-attach hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-attach
/Users/sebastian/.emacs.d/elpa/org-20130211/org-ascii hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-ascii
/Users/sebastian/.emacs.d/elpa/org-20130211/org-archive hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-archive
/Users/sebastian/.emacs.d/elpa/org-20130211/org-agenda hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/org-agenda
/Users/sebastian/.emacs.d/elpa/org-20130211/ob hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-tangle hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-tangle
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-table hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-table
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-sqlite hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-sqlite
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-sql hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-sql
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-shen hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-shen
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-sh hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-sh
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-screen hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-screen
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-scheme hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-scheme
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-scala hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-scala
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-sass hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-sass
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-ruby hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-ruby
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-ref hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-ref
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-R hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-R
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-python hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-python
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-plantuml hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-plantuml
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-picolisp hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-picolisp
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-perl hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-perl
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-org hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-org
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-octave hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-octave
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-ocaml hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-ocaml
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-mscgen hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-mscgen
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-maxima hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-maxima
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-matlab hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-matlab
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-lob hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-lob
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-lisp hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-lisp
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-lilypond hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-lilypond
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-ledger hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-ledger
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-latex hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-latex
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-keys hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-keys
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-js hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-js
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-java hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-java
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-io hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-io
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-haskell hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-haskell
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-gnuplot hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-fortran hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-fortran
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-exp hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-exp
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-eval hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-eval
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-emacs-lisp hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-dot hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-dot
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-ditaa hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-ditaa
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-css hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-css
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-comint hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-comint
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-clojure hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-clojure
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-calc hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-calc
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-C hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-C
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-awk hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-awk
/Users/sebastian/.emacs.d/elpa/org-20130211/ob-asymptote hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/org/ob-asymptote
/Users/sebastian/.emacs.d/elpa/magit-20130206.1334/.dir-locals hides /Volumes/Emacs/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils rainbow-mode
rainbow-delimiters paredit melpa auto-complete-clang preview-latex
tex-site auto-loads ob-tangle org-src ob-comint ob-keys ob org-compat
org-macs ob-eval helm-mode helm-files image-dired dired-x dired-aux ffap
helm-buffers helm-elscreen helm-tags helm-bookmark helm-adaptative
helm-info helm-net browse-url xml url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
url-vars mailcap helm-plugin helm-locate helm-help helm-match-plugin
helm-grep helm-regexp grep helm-external helm-utils dired compile evil
evil-integration evil-maps evil-commands evil-types evil-digraphs
evil-search evil-ex evil-macros evil-repeat evil-states evil-core
evil-common undo-tree diff rect evil-vars autopair pragmatic-light
pragmatic-light-theme auto-complete-config auto-complete popup
scroll-all cus-start cus-load prelude-osx exec-path-from-shell
prelude-global-keybindings prelude-editor esh-var esh-io esh-cmd esh-opt
esh-ext esh-proc esh-arg eldoc esh-groups eshell esh-module esh-mode
esh-util re-builder midnight helm-misc helm expand-region
text-mode-expansions python-el-fgallina-expansions expand-region-custom
expand-region-core icomplete ido etags volatile-highlights hl-line paren
windmove tramp-cache tramp-sh tramp tramp-compat auth-source gnus-util
mm-util mail-prsvr password-cache tramp-loaddefs shell pcomplete
format-spec recentf tree-widget wid-edit savehist saveplace uniquify
electric autorevert delsel prelude-mode prelude-core repeat thingatpt
prelude-ui server prelude-packages ace-jump-mode-autoloads
ack-and-a-half-autoloads auto-complete-autoloads
auto-complete-clang-autoloads autopair-autoloads ebib-autoloads
evil-autoloads exec-path-from-shell-autoloads expand-region-autoloads
gist-autoloads gh-autoloads eieio helm-autoloads helm-ls-git-autoloads
iedit-autoloads inf-ruby-autoloads js2-mode-autoloads logito-autoloads
magithub-autoloads magit-autoloads markdown-mode-autoloads
melpa-autoloads byte-opt warnings bytecomp byte-compile cconv advice
help-fns org-autoloads info pcache-autoloads finder-inf popup-autoloads
prelude-c-autoloads prelude-css-autoloads prelude-emacs-lisp-autoloads
prelude-lisp prelude-haskell-autoloads haskell-mode-autoloads
prelude-js-autoloads prelude-lisp-autoloads edmacro kmacro
paredit-autoloads prelude-perl-autoloads prelude-python-autoloads python
rx easymenu comint ring ansi-color prelude-programming-autoloads
which-func imenu guru-mode-autoloads python-autoloads
rainbow-delimiters-autoloads rainbow-mode-autoloads
solarized-theme-autoloads sunrise-commander-autoloads tagedit-autoloads
dash-autoloads s-autoloads undo-tree-autoloads
volatile-highlights-autoloads watch-buffer-autoloads yari-autoloads
zenburn-theme-autoloads package cl-macs gv cl nadvice cl-lib time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

Message #8 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Sebastian Sturm <sebastian.sturm <at> uni-leipzig.de>
Cc: 13709 <at> debbugs.gnu.org
Subject: Re: bug#13709: 24.3.50; Evil breaks Meta on r111745
Date: Thu, 14 Feb 2013 09:32:19 -0500

> With evil mode activated (using evil-20130212.906), the Meta key is not
> recognized anymore (i.e., pressing M-q displays the error message "M-q
> is undefined", even though C-h k M-q shows that M-q is bound to
> fill-paragraph). With r111730, everything works as expected.

It's probably due to my messing with read_key_sequence.  I'll try and
get Evil going here to try and reproduce the problem.  In the mean time,
can you confirm that the above test work in a "minimally configured Emacs"
(basically "emacs -Q" followed by loading Evil)?


        Stefan

Message #11 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Sturm <sebastian.sturm <at> uni-leipzig.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 13709 <at> debbugs.gnu.org
Subject: Re: bug#13709: 24.3.50; Evil breaks Meta on r111745
Date: Thu, 14 Feb 2013 15:46:31 +0100

>> With evil mode activated (using evil-20130212.906), the Meta key is not
>> recognized anymore (i.e., pressing M-q displays the error message "M-q
>> is undefined", even though C-h k M-q shows that M-q is bound to
>> fill-paragraph). With r111730, everything works as expected.
> 
> It's probably due to my messing with read_key_sequence.  I'll try and
> get Evil going here to try and reproduce the problem.  In the mean time,
> can you confirm that the above test work in a "minimally configured Emacs"
> (basically "emacs -Q" followed by loading Evil)?

yes, the same problem occurs with Emacs -Q, evil-mode loaded manually.
thanks,
Sebastian

Message #14 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org,
	Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Sun, 24 Feb 2013 22:55:34 -0500

> Meta bindings do not work if Emacs is started in X and viper is
> enabled. To reproduce, type

>   emacs -Q
>   M-x viper RET
>   M-x

> the last command M-x shows 'M-x undefined'.

I can reproduce it here, but it's tricky to investigate because of all
the various keymap trickery.  The thing I noticed is that in emacs-24,
`f1 k M-x' also tells me "M-x is undefined" although M-x does work.

> As far as I can tell, the reason is viper's trick with the ESC
> key. viper binds (kbd "ESC") to a special command call
> `viper-intercept-ESC-key`.

AFAICT in the GUI case, viper-intercept-ESC-key is not called when you
hit M-x (at least that's what trace-function-background told me, both in
trunk and in emacs-24).

The same commit caused a problem in Evil as well (see bug#13709), and
I hope the problem is the same and can be fixed in the same way, but I'm
also having trouble figuring out what's happening in that case.

If someone familiar with Evil or Viper's keymap tricks could investigate
a bit more to try and see where the behavior changes, I can then
hopefully see how it relates to my read-key-sequence changes.


        Stefan

Message #17 received at 13709 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Mon, 25 Feb 2013 21:16:57 +0100

On 02/24, Stefan Monnier wrote:
> The same commit caused a problem in Evil as well (see bug#13709), and
> I hope the problem is the same and can be fixed in the same way, but I'm
> also having trouble figuring out what's happening in that case.
> 
> If someone familiar with Evil or Viper's keymap tricks could investigate
> a bit more to try and see where the behavior changes, I can then
> hopefully see how it relates to my read-key-sequence changes.

Coincidentally, I'm involved with Evil, but I've never tried to debug
Emacs' C code. But I think I succeeded and can explain what's going
on. I will restrict to Evil, because I know it better than viper. I
start with a description of what Evil does and afterwards describe the
problem with the new code.

The problem, as I said, is that Evil needs to differentiate between a
plain ESC key and a meta key sequence. Evil does the following. It has
a special minor mode `evil-esc-mode` along with its keymap
`evil-esc-map`. This keymap has only one binding, (kbd "ESC") is bound
to a function `evil-esc`. This function is very simple (I removed some
code, but they main idea should become clear)

	(defun evil-esc (arg)
	  "Wait for further keys within `evil-esc-delay'.
	Otherwise send [escape]."
	  (interactive "P")
	  (if (sit-for evil-esc-delay t)
		  (push 'escape unread-command-events)
		(push last-command-event unread-command-events)
		;; preserve prefix argument
		(setq prefix-arg arg))
	  ;; disable interception for the next key sequence
	  (evil-esc-mode -1)
	  (setq this-command last-command)
	  (add-hook 'pre-command-hook #'evil-turn-on-esc-mode nil t))

The function waits for the next event. If it arrives, the (kbd "ESC")
event is unread, and evil-esc-mode is disabled so that it does not
call again `evil-esc`. If no next event arrives the event 'escape is
unread so whatever command is bound to 'escape will be called.
`evil-esc-mode` will be reenabled after the next command completed.
Note that an event like M-x (in the terminal) generates two events in
quick succession, namely (kbd "ESC") and "x", so the first case
happens. In GUI mode the function `evil-esc` is never called because
here M-x generates another event (some large integer). This event is
transformed to an ESC sequence, too, but not using `evil-esc` but
within the function `access_keymap_1` in file `keymap.c`.

If this function detects that the event is a meta event, it looks for
the prefix map of (kbd "ESC") in the keymap that has been passed to
the function in the "map" argument. Here comes the problem.

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.

After the commit all keymaps are collected in one single "super"
keymap, that contains all keymaps as "parents" (is this correct?). Now
`access_keymap_1` gets only called once for this super keymap. Again
this function tries to find (kbd "ESC") in this keymap. This will
return the binding of `evil-esc`, which is not a prefix keymap so no
binding will be found. Because of how keymaps work only the first
binding of (kbd "ESC") in one of the parent keymaps will be returned,
and this is `evil-esc`.

The get the old behaviour, `access_keymap_1` would have to check all
parent keymaps in turn. For each keymap that bind (kbd "ESC") to
another keymap it would have to check the second key.

I hope this helps. Sorry that I do not provide a patch, but currently
my "Emacs-C" is too bad for this.

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.

If my explanations are unclear, please tell ;)

Best regards,
Frank

Message #20 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org,
	Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Mon, 25 Feb 2013 16:35:58 -0500

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

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

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


        Stefan

Message #23 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Michael Kifer <michael.kifer <at> stonybrook.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "13793 <at> debbugs.gnu.org" <13793 <at> debbugs.gnu.org>,
	"13709 <at> debbugs.gnu.org" <13709 <at> debbugs.gnu.org>,
	Frank Fischer <frank-fischer <at> shadow-soft.de>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 02:17:44 -0500

[Message part 1 (text/html, inline)]

Message #26 received at 13709 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 09:57:42 +0100

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

Message #29 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org,
	Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 09:10:28 -0500

>> [ 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?

I guess an advice might work (it probably wouldn't need to put the map
back, just let-bind a variable that causes the filter function to return
evil-normal-esc-map without bothering to sit-for).
But it doesn't sound very appealing.

Maybe "enable evil-esc-mode in post-command-hook and disable it in
pre-command-hook" might work?


        Stefan

Message #32 received at 13709 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 15:56:08 +0100

On 02/26, Stefan Monnier wrote:
> >> [ 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?
> 
> I guess an advice might work (it probably wouldn't need to put the map
> back, just let-bind a variable that causes the filter function to return
> evil-normal-esc-map without bothering to sit-for).
> But it doesn't sound very appealing.
> 
> Maybe "enable evil-esc-mode in post-command-hook and disable it in
> pre-command-hook" might work?

I'm a little bit afraid of situations where a new binding is defined
but pre-command-hook has not been called (to restore the original
definition of `input-decode-map`). For example if a new binding is
established in a hook or when Emacs starts. If evil is loaded before
that binding is defined, i.e. input-decode-map is already 'patched',
then it may fail. Of course one could start with an unpatched
input-decode-map and wait for the first post-command-hook.

So the question is: is it guaranteed that a post-command-hook will be
called when Emacs starts and before any user input, and that a call to
`define-key` will always be preceded by a pre-command-hook and
followed by a post-command-hook, no matter how it is called? This
includes any possibility to call `define-key` from a hook or so. I
just do not have the overview to give a reliable judgement on this.
IMO using an advice is more direct and simpler in this particular
situation, although I really don't like it.

Frank

Message #35 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org,
	Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Tue, 26 Feb 2013 13:12:01 -0500

>> Maybe "enable evil-esc-mode in post-command-hook and disable it in
>> pre-command-hook" might work?
> I'm a little bit afraid of situations where a new binding is defined
> but pre-command-hook has not been called (to restore the original
> definition of `input-decode-map`). For example if a new binding is
> established in a hook or when Emacs starts. If evil is loaded before
> that binding is defined, i.e. input-decode-map is already 'patched',
> then it may fail. Of course one could start with an unpatched
> input-decode-map and wait for the first post-command-hook.

Agreed, using post/pre-command-hook is messy.  Other problems come up
with recursive edits (and minibuffers), where the pre-command-hook can
end up run twice without intervening post-command-hook and
post-command-hook can similarly be run twice without an intervening
pre-command-hook.

> So the question is: is it guaranteed that a post-command-hook will be
> called when Emacs starts and before any user input, and that a call to
> `define-key` will always be preceded by a pre-command-hook and
> followed by a post-command-hook, no matter how it is called?

No, basically with pre/post-command-hook, nothing is guaranteed.

> This includes any possibility to call `define-key` from a hook or
> so.  I just do not have the overview to give a reliable judgement on
> this.  IMO using an advice is more direct and simpler in this
> particular situation, although I really don't like it.

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


        Stefan

Message #38 received at 13709 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #41 received at 13709 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Wed, 27 Feb 2013 18:59:36 +0100

On 02/26, Frank Fischer wrote:
> 
> Sounds good to me. At least, I can't think of a problematic situation,
> currently. Let's how it works in practise.

Ok, now I have problem. The keymap `input-decode-map` is
keyboard-local (according to the documentation). This means (and this
makes sense because the ESC prefix map in `input-decode-map` is
different for each keyboard) we have to 'patch' it for each new
keyboard. Unfortunately, I'm not sure how to do this right.
Currently I use an `after-make-frame-functions` hook and a
`delete-terminal-functions` hook (although the latter may not be
required) to save the original prefix map in the terminal parameter
`evil-esc-map` and change `input-decode-map` accordingly. I hope that
this sets the correct values for each "keyboard".

Is this the correct way to do? Or is it completely wrong ;)

Best regards,
Frank

Message #44 received at 13709 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 13793 <at> debbugs.gnu.org, 13709 <at> debbugs.gnu.org,
	Michael Kifer <kifer <at> cs.stonybrook.edu>
Subject: Re: bug#13793: 24.3.50; M-x broken in viper and X
Date: Wed, 27 Feb 2013 14:08:31 -0500

>> Sounds good to me.  At least, I can't think of a problematic situation,
>> currently.  Let's how it works in practise.
> Ok, now I have problem. The keymap `input-decode-map` is
> keyboard-local (according to the documentation).

Indeed it is, but that shouldn't be too hard to handle.

> This means (and this makes sense because the ESC prefix map in
> `input-decode-map` is different for each keyboard) we have to 'patch'
> it for each new keyboard.

Yes.

> Unfortunately, I'm not sure how to do this right.
> Currently I use an `after-make-frame-functions` hook and a
> `delete-terminal-functions` hook (although the latter may not be
> required) to save the original prefix map in the terminal parameter
> `evil-esc-map` and change `input-decode-map` accordingly. I hope that
> this sets the correct values for each "keyboard".

> Is this the correct way to do? Or is it completely wrong ;)

That sounds fine.  It would be better to use make-terminal-functions, but
you'd have to invent that hook first ;-(
BTW, you can take advantage of this opportunity to only install this
hack on tty terminals.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.