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: Wed, 06 Feb 2013 22:33:38 -0800 Message-ID: <87lib01vlp.fsf@priss.frightenedpiglet.com> References: <87r4kwjx11.fsf@priss.frightenedpiglet.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360218832 7230 80.91.229.3 (7 Feb 2013 06:33:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 06:33:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 07 07:34:13 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 1U3L3l-00007d-CG for ged-emacs-devel@m.gmane.org; Thu, 07 Feb 2013 07:34:13 +0100 Original-Received: from localhost ([::1]:48708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3L3S-0005x5-IM for ged-emacs-devel@m.gmane.org; Thu, 07 Feb 2013 01:33:54 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3L3O-0005wh-OP for emacs-devel@gnu.org; Thu, 07 Feb 2013 01:33:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3L3M-00038V-BD for emacs-devel@gnu.org; Thu, 07 Feb 2013 01:33:50 -0500 Original-Received: from smtp61.avvanta.com ([206.124.128.61]:49444 helo=mail.avvanta.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3L3M-000375-2T for emacs-devel@gnu.org; Thu, 07 Feb 2013 01:33:48 -0500 Original-Received: from mail.avvanta.com (localhost.drteeth.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id CF654F3937 for ; Wed, 6 Feb 2013 22:33:45 -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 B7B72F3936 for ; Wed, 6 Feb 2013 22:33:45 -0800 (PST) Original-Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss with esmtp (Exim 4.80) (envelope-from ) id 1U3L3C-0000pl-31 for emacs-devel@gnu.org; Wed, 06 Feb 2013 22:33:38 -0800 User-agent: mu4e 0.9.9.5-dev6; emacs 24.2.2 In-reply-to: <87r4kwjx11.fsf@priss.frightenedpiglet.com> X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.drteeth.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:156845 Archived-At: Here's a small repro case for the problem. Start up two instances of Emacs, and load this file into both. In the first, run `bad-keymap-startup-server'. In the second, run `bad-keymap-send-signal', and immediately switch back to the first Emacs. The first Emacs will switch to a "*foo*" buffer with some dummy text. That buffer will be in view mode. If you hit `q' after the buffer pops up, Emacs will complain about "*foo*" being read-only. Hit `q' again and the buffer disappears. Kill the "*foo*" buffer and run the test again. This time, instead of hitting `q', use `C-n' to move down a line. After that, when you hit `q' you exit view mode immediately. In the original code, I had theorized that the event was going to the read-only temporary buffer, which had no binding for `q'. But if that were the case, we would see different behavior when the "old" buffer is the writable "bad-keymap.el". The "*foo*" buffer is getting the `q' event, but it looks like read_char() has not started using the buffer's new `view-mode' keymap, due to the way we are jumping to "retry:". The proposed fix to exit read_char() after every special event gives the I/O system a chance to see the new keymap. Derek ------------------------- bad-keymap.el ------------------------- (require 'dbus) (defun bad-keymap-switch-handler () (let* ((buf (get-buffer-create "*foo*"))) (with-current-buffer buf (let ((inhibit-read-only t)) (erase-buffer) (insert "foo foo foo\n") (switch-to-buffer buf) (goto-char (point-min))) (view-mode)))) (defun bad-keymap-startup-server () (interactive) (dbus-register-signal :session "bad-keymap" "/bad/keymap" "bad.keymap" "Switch" 'bad-keymap-switch-handler)) (defun bad-keymap-send-signal () (interactive) (sit-for 5) (dbus-send-signal :session "bad-keymap" "/bad/keymap" "bad.keymap" "Switch")) ----------------------------------------------------------------- Derek Upham writes: > There is an Emacs package that uses process buffers to communicate with a > spawned worker process. Due to locking on underlying files, this limits > me to one worker, and hence one Emacs. I'm trying to add D-Bus support > to both sides, and have come across a bug in Emacs' support for special > events. > > The package includes a chunk of code that: > > 1. Brings up a temporary buffer in a visible window. > 2. Queries the worker through the process buffer channel. > 3. Handles the worker's response in a process filter handler, putting > the text into a new buffer and replacing the temporary buffer in the > same window. > > The D-Bus code attempts to do the exact same steps, and appears to > succeed. But the first event after displaying the response (usually a > keystroke) goes to the /temporary buffer/, generating a "buffer > read-only" error. After the error, the command loop resyncs the current > buffer to the visible buffer and later events work normally. > > I ran Emacs 24.2.2 in GDB and found that the read_char() function has > code that is supposed to detect this case: > > 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; > > However, `current_buffer' and `prev_buffer' are showing up as the same > in the debugger. I think this is because we haven't gone through a > display refresh at this point in the code; the Emacs window still shows > the temporary buffer, for example. This specific error case affects > D-Bus, but any similar activity by a special event handler should show > the same bug. > > I have a fix that seems to work: remove the test and assume that any > special event handler could have changed the keymaps. > > /* 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 potential optimization, as the code goes up to a higher > level before restarting `read_char'. But looking at the list of > special events (in `special-event-map'), those special events should be > infrequent enough that this change won't cause a performance impact. > Does anyone know of a reason not to make this change? > > Thanks, > > Derek -- Derek Upham sand@blarg.net