From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#4093: Overlay keymap and timers Date: Mon, 10 Aug 2009 12:25:30 -0400 Message-ID: References: <680d89b1d020330a6cb4001845e1e5fb@bazon.net> <8d0e98985fc5a0229f138935490f4f6a@bazon.net> Reply-To: Stefan Monnier , 4093@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249923279 2545 80.91.229.12 (10 Aug 2009 16:54:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2009 16:54:39 +0000 (UTC) Cc: 4093@emacsbugs.donarmstrong.com To: Mihai Bazon Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 10 18:54:32 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MaY8l-0002JM-SO for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Aug 2009 18:54:32 +0200 Original-Received: from localhost ([127.0.0.1]:42183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaY8l-0002v8-1C for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Aug 2009 12:54:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaY8V-0002ox-L3 for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 12:54:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaY8Q-0002nT-3U for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 12:54:14 -0400 Original-Received: from [199.232.76.173] (port=36111 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaY8P-0002nQ-UV for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 12:54:09 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44659) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MaY8P-0002sl-Bn for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2009 12:54:09 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7AGkmMX005217; Mon, 10 Aug 2009 09:46:49 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n7AGZ5k1003938; Mon, 10 Aug 2009 09:35:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 10 Aug 2009 16:35:05 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4093 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4093-submit@emacsbugs.donarmstrong.com id=B4093.12499215333235 (code B ref 4093); Mon, 10 Aug 2009 16:35:05 +0000 Original-Received: (at 4093) by emacsbugs.donarmstrong.com; 10 Aug 2009 16:25:33 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from tomts16-srv.bellnexxia.net (tomts16-srv.bellnexxia.net [209.226.175.4]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7AGPV0l003232 for <4093@emacsbugs.donarmstrong.com>; Mon, 10 Aug 2009 09:25:32 -0700 Original-Received: from toip6.srvr.bell.ca ([209.226.175.125]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090810162530.FUWP13336.tomts16-srv.bellnexxia.net@toip6.srvr.bell.ca> for <4093@emacsbugs.donarmstrong.com>; Mon, 10 Aug 2009 12:25:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANvkf0pGN48s/2dsb2JhbACBUs8JhBgF Original-Received: from bas1-montreal42-1178046252.dsl.bell.ca (HELO ceviche.home) ([70.55.143.44]) by toip6.srvr.bell.ca with ESMTP; 10 Aug 2009 12:18:14 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 2FE1DB454F; Mon, 10 Aug 2009 12:25:30 -0400 (EDT) In-Reply-To: <8d0e98985fc5a0229f138935490f4f6a@bazon.net> (Mihai Bazon's message of "Mon, 10 Aug 2009 09:55:24 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Mon, 10 Aug 2009 12:54:14 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30063 Archived-At: >> > Yes, this is a really bad thing - sometimes, ie when you need to do >> > just that. >> The code in keyboard.c reads the set of active keymaps before reading >> the next event. That's most likely the explanation for this behavior. > What you are saying does actually make sense. If it set the keymap > *before* serving an event, it should work fine. But I think what > happens is that it sets the keymap *after* executing an event... > I looked at the code but couldn't figure out where is the keymap > computed. Could you point it out? The relevant code is in .... read_key_sequence! (only those who've had to deal with this function understand the "...."). You'll see that it first collects all the active keyamps (see where it calls current_minor_maps), and later on calls read_char (which can do redisplay, run timers, run process filters, etc...). Basically the problem in the case of changing the keymap from a timer comes down to: what happens if the use presses C-c, then your code runs then the user presses C-d: should the C-c C-d be looked up in the original keymaps or in the new keymaps? you worry about the case where the timer is run before the C-c, but from Emacs's current point of view, it's no different whether the timer is run after 1 key-press, or after 2 key-presses, or after 0 key-presses. We can probably change the code to collect the list of active keymaps later (e.g. right after the first key-press). But maybe an alternative is to provide some way for your Elisp code to cause a jump back to `replay_sequence' so that you can force the C-c C-d to be interpreted in the new keymaps even if the C-c had already been pressed when your code was run. In any case, this function is a monster, so I'll only consider changes to it if it makes it simpler (typically by moving code out of it into some new function). Maybe the idea of a new "need-to-replay-sequence" variable could be a good way to simplify the code: we could maybe arrange for most other "goto replay_sequence" to use this new var (i.e. replace the current code that checks some relevant condition, by some piece of code elsewhere (where that condition is created) which sets the var). Stefan