From: Derek Upham <sand@blarg.net>
To: emacs-devel@gnu.org
Subject: Re: read_char() does not detect, handle special-event-map buffer changes
Date: Thu, 07 Feb 2013 06:50:09 -0800 [thread overview]
Message-ID: <87k3qk18m6.fsf@priss.frightenedpiglet.com> (raw)
In-Reply-To: <87lib01vlp.fsf@priss.frightenedpiglet.com>
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
next prev parent reply other threads:[~2013-02-07 14:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 8:36 read_char() does not detect, handle special-event-map buffer changes Derek Upham
2013-02-07 6:33 ` Derek Upham
2013-02-07 14:50 ` Derek Upham [this message]
2013-02-07 16:25 ` Stefan Monnier
2013-02-08 4:39 ` Derek Upham
2013-02-08 7:35 ` Michael Albinus
2013-02-08 15:32 ` Derek Upham
2013-02-08 16:11 ` Michael Albinus
2013-02-09 5:31 ` Derek Upham
2013-02-11 19:22 ` Stefan Monnier
2013-02-12 5:29 ` Derek Upham
2013-02-12 14:02 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k3qk18m6.fsf@priss.frightenedpiglet.com \
--to=sand@blarg.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.