From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Derek Upham Newsgroups: gmane.emacs.devel Subject: Re: read_char() does not detect, handle special-event-map buffer changes Date: Thu, 07 Feb 2013 20:39:42 -0800 Message-ID: <87haln1ks1.fsf@priss.frightenedpiglet.com> References: <87r4kwjx11.fsf@priss.frightenedpiglet.com> <87lib01vlp.fsf@priss.frightenedpiglet.com> <87k3qk18m6.fsf@priss.frightenedpiglet.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360298399 28794 80.91.229.3 (8 Feb 2013 04:39:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 04:39:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 08 05:40:19 2013 Return-path: Envelope-to: ged-emacs-devel@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 1U3fl1-0000jI-S9 for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2013 05:40:15 +0100 Original-Received: from localhost ([::1]:32871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3fki-0003jt-Pp for ged-emacs-devel@m.gmane.org; Thu, 07 Feb 2013 23:39:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3fkf-0003jj-QH for emacs-devel@gnu.org; Thu, 07 Feb 2013 23:39:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3fke-00033y-Dg for emacs-devel@gnu.org; Thu, 07 Feb 2013 23:39:53 -0500 Original-Received: from smtp61.avvanta.com ([206.124.128.61]:53276 helo=mail.avvanta.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3fke-00033s-54 for emacs-devel@gnu.org; Thu, 07 Feb 2013 23:39:52 -0500 Original-Received: from mail.avvanta.com (localhost.rowlf.p [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 1D53D93C4F; Thu, 7 Feb 2013 20:39:51 -0800 (PST) Original-Received: from priss.frightenedpiglet.com (c-24-16-15-52.hsd1.wa.comcast.net [24.16.15.52]) by mail.avvanta.com (Postfix) with ESMTP id E366B93C13; Thu, 7 Feb 2013 20:39:50 -0800 (PST) Original-Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss with esmtp (Exim 4.80) (envelope-from ) id 1U3fkU-0005Ne-R7; Thu, 07 Feb 2013 20:39:42 -0800 User-agent: mu4e 0.9.9.5-dev6; emacs 24.2.2 In-reply-to: X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.scooter.p.blarg.net X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 206.124.128.61 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156878 Archived-At: Stefan Monnier writes: >> in a separate terminal. Move focus back to Emacs before the signal goes >> out. Hit `q' in the new buffer and Emacs will complain about "*foo*" >> being read-only. The second time you hit `q', Emacs will exit view mode >> and bury the buffer. > > I think this is a known problem: the set of active keymaps is determined > at the end of the previous command, so any change performed via > something like a special-event-map binding or a process-filter will bump > into this problem (you don't even need to switch-to-buffer, just > enabling view-mode is sufficient). > > It's a bug: we should instead wait until the first key is pressed > before figuring out the active keymaps. > Problem is, this bug is in read_key_sequence, which is a pretty > scary function. > > In the mean time, you can work around the bug by adding to > unread-command-event (from your sigusr1-handler) a dummy event that is > bound in global-map to something like `ignore'. > > > Stefan Did you see my comment in the original email? read_char() is already trying to detect changed keymaps. if (current_buffer != prev_buffer) { /* The command may have changed the keymaps. Pretend there is input in another keyboard and return. This will recalculate keymaps. */ c = make_number (-2); goto exit; } else goto retry; The bug is happening because the test is flawed: current_buffer and prev_buffer are the same, so Emacs doesn't think it needs to recalculate anything. It loops back to the top of read_char() and reads another character with the same keymap. Removing the retry case and exiting every time fixes the problem: /* The command may have changed the keymaps. Pretend there is input in another keyboard and return. This will recalculate keymaps. */ c = make_number (-2); goto exit; This removes a flawed optimization and returns a documented value. It doesn't touch read_key_sequence, so that risk goes away. If we were getting special events at a high rate of speed this /might/ cause a slowdown, but nothing in the special events table seems to be used that way---and I expect that the extra time spent popping back up to read_key_sequence for the retry will still be very fast compared to the time spent in the Emacs Lisp callback. Derek -- Derek Upham sand@blarg.net