From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mihai Bazon Newsgroups: gmane.emacs.bugs Subject: bug#4093: Overlay keymap and timers Date: Tue, 11 Aug 2009 19:49:39 +0300 Message-ID: <3db84103d8c5db51b3dd6bba4c267a84@bazon.net> References: <680d89b1d020330a6cb4001845e1e5fb@bazon.net> <8d0e98985fc5a0229f138935490f4f6a@bazon.net> Reply-To: Mihai Bazon , 4093@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF8" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250010703 2173 80.91.229.12 (11 Aug 2009 17:11:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 17:11:43 +0000 (UTC) Cc: 4093@emacsbugs.donarmstrong.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 11 19:11:36 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 1Mausp-0004SC-20 for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Aug 2009 19:11:35 +0200 Original-Received: from localhost ([127.0.0.1]:43803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mausn-0005Xk-E8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Aug 2009 13:11:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MauoM-0003bN-E7 for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 13:06:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MauoH-0003Yx-2a for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 13:06:57 -0400 Original-Received: from [199.232.76.173] (port=38039 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MauoG-0003Yd-IL for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 13:06:52 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:43347) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MauoF-0004AS-KA for bug-gnu-emacs@gnu.org; Tue, 11 Aug 2009 13:06:52 -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 n7BH6mWM000825; Tue, 11 Aug 2009 10:06:49 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n7BH0472031715; Tue, 11 Aug 2009 10:00:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Mihai Bazon Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 11 Aug 2009 17:00:04 +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.125000960731134 (code B ref 4093); Tue, 11 Aug 2009 17:00:04 +0000 Original-Received: (at 4093) by emacsbugs.donarmstrong.com; 11 Aug 2009 16:53:27 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from v1.dynarch.com (ip-72-55-183-145.static.privatedns.com [72.55.183.145]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7BGrPGJ031131 for <4093@emacsbugs.donarmstrong.com>; Tue, 11 Aug 2009 09:53:27 -0700 Original-Received: by v1.dynarch.com (Postfix, from userid 5001) id 4E8A61D80003; Tue, 11 Aug 2009 19:49:40 +0300 (EEST) Original-Received: from v3.dynarch.com (ip-72-55-183-147.static.privatedns.com [72.55.183.147]) by v1.dynarch.com (Postfix) with SMTP id 61B3D1D80003; Tue, 11 Aug 2009 19:49:39 +0300 (EEST) Original-Received: (nullmailer pid 1625 invoked by uid 65534); Tue, 11 Aug 2009 16:49:39 -0000 Content-Disposition: inline In-Reply-To: X-Mailer: XUHEKI - Dynarch.com WebMail X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Tue, 11 Aug 2009 13:06:57 -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:30107 Archived-At: Indeed, that function looks frightening. It's worth noting that XEmacs doesn't have this problem. But the code differs drastically.. Hard to figure out a simple fix. -M Stefan Monnier wrote: > >> > 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... >=20 > > I looked at the code but couldn't figure out where is the keymap > > computed. Could you point it out? >=20 > The relevant code is in .... read_key_sequence! (only those who've had > to deal with this function understand the "...."). >=20 > 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...). >=20 > Basically the problem in the case of changing the keymap from a timer > comes down to: >=20 > 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? >=20 > 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. >=20 > 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. >=20 > 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). >=20 >=20 > Stefan=