Re: read_char() does not detect, handle special-event-map buffer changes

[Derek Upham <sand@blarg.net>]

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