From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Frank Fischer Newsgroups: gmane.emacs.bugs Subject: bug#13709: bug#13793: 24.3.50; M-x broken in viper and X Date: Mon, 25 Feb 2013 21:16:57 +0100 Message-ID: <20130225201657.GA10969@susi> References: <20130223123501.43568c52@susi> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1361823641 24530 80.91.229.3 (25 Feb 2013 20:20:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Feb 2013 20:20:41 +0000 (UTC) Cc: 13793@debbugs.gnu.org, 13709@debbugs.gnu.org, Michael Kifer To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 25 21:21:01 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UA4Xg-0004CL-V3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 21:20:57 +0100 Original-Received: from localhost ([::1]:47210 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4XM-0007CH-6F for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 15:20:36 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4XE-0007Bf-Se for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:20:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UA4X7-0005Qt-Ud for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:20:28 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4X7-0005Qo-Qw for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:20:21 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UA4Yk-0002Rf-57 for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Frank Fischer Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Feb 2013 20:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13709 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13709-submit@debbugs.gnu.org id=B13709.13618236839353 (code B ref 13709); Mon, 25 Feb 2013 20:22:02 +0000 Original-Received: (at 13709) by debbugs.gnu.org; 25 Feb 2013 20:21:23 +0000 Original-Received: from localhost ([127.0.0.1]:50020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA4Y6-0002Qh-D2 for submit@debbugs.gnu.org; Mon, 25 Feb 2013 15:21:23 -0500 Original-Received: from mout1.freenet.de ([195.4.92.91]:49799) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA4Y2-0002QT-Vb; Mon, 25 Feb 2013 15:21:20 -0500 Original-Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout1.freenet.de with esmtpa (ID frank-fischer@shadow-soft.de) (port 25) (Exim 4.80.1 #2) id 1UA4WM-0007dr-H1; Mon, 25 Feb 2013 21:19:34 +0100 Original-Received: from localhost ([::1]:47580 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID frank-fischer@shadow-soft.de) (Exim 4.80.1 #2) id 1UA4WM-0008Kl-Bd; Mon, 25 Feb 2013 21:19:34 +0100 Original-Received: from [195.4.92.21] (port=53762 helo=11.mx.freenet.de) by mjail1.freenet.de with esmtpa (ID frank-fischer@shadow-soft.de) (Exim 4.80.1 #2) id 1UA4U2-0001jw-Aj; Mon, 25 Feb 2013 21:17:10 +0100 Original-Received: from i59f6a57b.versanet.de ([89.246.165.123]:56260 helo=susi) by 11.mx.freenet.de with esmtpsa (ID frank-fischer@shadow-soft.de) (TLSv1.1:DHE-RSA-AES256-SHA:256) (port 465) (Exim 4.80.1 #2) id 1UA4U1-0001Dk-Rh; Mon, 25 Feb 2013 21:17:10 +0100 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/0.94.10i+5398 (706058bd5660) (2011-07-01) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71797 Archived-At: 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