[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
read_char() does not detect, handle special-event-map buffer changes
From: |
Derek Upham |
Subject: |
read_char() does not detect, handle special-event-map buffer changes |
Date: |
Mon, 04 Feb 2013 00:36:26 -0800 |
User-agent: |
mu4e 0.9.9.5-dev6; emacs 24.2.2 |
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
address@hidden
- read_char() does not detect, handle special-event-map buffer changes,
Derek Upham <=
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/07
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/07
- Re: read_char() does not detect, handle special-event-map buffer changes, Stefan Monnier, 2013/02/07
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/07
- Re: read_char() does not detect, handle special-event-map buffer changes, Michael Albinus, 2013/02/08
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/08
- Re: read_char() does not detect, handle special-event-map buffer changes, Michael Albinus, 2013/02/08
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/09
- Re: read_char() does not detect, handle special-event-map buffer changes, Stefan Monnier, 2013/02/11
- Re: read_char() does not detect, handle special-event-map buffer changes, Derek Upham, 2013/02/12