From: Derek Upham <sand@blarg.net>
To: emacs-devel@gnu.org
Subject: read_char() does not detect, handle special-event-map buffer changes
Date: Mon, 04 Feb 2013 00:36:26 -0800 [thread overview]
Message-ID: <87r4kwjx11.fsf@priss.frightenedpiglet.com> (raw)
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 reply other threads:[~2013-02-04 8:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 8:36 Derek Upham [this message]
2013-02-07 6:33 ` read_char() does not detect, handle special-event-map buffer changes Derek Upham
2013-02-07 14:50 ` Derek Upham
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4kwjx11.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).