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 06:50:09 -0800 Message-ID: <87k3qk18m6.fsf@priss.frightenedpiglet.com> References: <87r4kwjx11.fsf@priss.frightenedpiglet.com> <87lib01vlp.fsf@priss.frightenedpiglet.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360248636 31910 80.91.229.3 (7 Feb 2013 14:50:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 14:50:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 07 15:50:57 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 1U3SoQ-0006rJ-2a for ged-emacs-devel@m.gmane.org; Thu, 07 Feb 2013 15:50:54 +0100 Original-Received: from localhost ([::1]:55867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3So7-00064X-A2 for ged-emacs-devel@m.gmane.org; Thu, 07 Feb 2013 09:50:35 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3So3-00064P-9u for emacs-devel@gnu.org; Thu, 07 Feb 2013 09:50:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3Snv-0006RS-Jm for emacs-devel@gnu.org; Thu, 07 Feb 2013 09:50:29 -0500 Original-Received: from smtp61.avvanta.com ([206.124.128.61]:55377 helo=mail.avvanta.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Snv-0006Pa-AV for emacs-devel@gnu.org; Thu, 07 Feb 2013 09:50:23 -0500 Original-Received: from mail.avvanta.com (localhost.pops.p.blarg.net [127.0.0.1]) by mail.avvanta.com (Postfix) with ESMTP id 21C12276CD9 for ; Thu, 7 Feb 2013 06:50:17 -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 009F0276CD0 for ; Thu, 7 Feb 2013 06:50:17 -0800 (PST) Original-Received: from localhost ([127.0.0.1] helo=priss.frightenedpiglet.com) by priss with esmtp (Exim 4.80) (envelope-from ) id 1U3Snh-0000VK-B9 for emacs-devel@gnu.org; Thu, 07 Feb 2013 06:50:09 -0800 User-agent: mu4e 0.9.9.5-dev6; emacs 24.2.2 In-reply-to: <87lib01vlp.fsf@priss.frightenedpiglet.com> X-BlargAV-Status: No viruses detected, BlargAV v1.1 on localhost.pops.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:156855 Archived-At: Here's an even smaller repro case. Eval the following in an Emacs instance: (defun sigusr1-handler () (interactive) (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)))) (define-key special-event-map [sigusr1] 'sigusr1-handler) Then run sleep 5; kill -USR1 $EMACS_PID 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. Derek Derek Upham writes: > 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