all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Emacs routinely gets stuck in single_kboard mode
@ 2004-06-07  7:45 Lőrentey Károly
  2004-06-13 21:49 ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Lőrentey Károly @ 2004-06-07  7:45 UTC (permalink / raw)
  Cc: multi-tty

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

Emacs has support for multiple X displays, each with their own
keyboard.  (The multi-tty branch uses the same mechanism to support
more than one tty device.)  To prevent interference from another
keyboard, Emacs sets single_kboard while reading from the minibuffer
or executing an interactive command.  When that variable is set, input
from other keyboards is stacked away unprocessed until it is reset to
zero.  Unfortunately, in some cases Emacs fails to clear
single_kboard, which causes problems.  For example, try the following
commands on a system that supports X forwarding via local ssh
connections:

        $ ssh -X localhost      # Create an alias for the current display
        Password: ******
          $ echo $DISPLAY
	  localhost:10
          $

        Then, from another terminal:

	$ emacs -q --no-site-file -f ignore	# Note the -f parameter!
        M-x make-frame-on-display <RET> localhost:10 <RET>

make-frame-on-display should succeed creating a new frame on the
forwarded X connection, but the new frame does not accept input; not
even C-g.  (Make sure you don't press C-g in the first frame, because
it unconditionally resets single_kboard and thus unfreezes the other
frame.)  The bug is triggered by specifying an interactive command to
be executed by the -f option.

But this is not the only time Emacs gets stuck in single_kboard mode.
Here is another (more frequent) case:

	$ emacs -q --no-site-file
        M-x make-frame-on-display <RET> localhost:10 <RET>
        slartibartfast C-x C-e    # void-variable error

        ==> The other frame is locked up, which might be
            intentional.  But exiting the debugger by
            pressing q does not help, which is certainly a bug.

(Pressing C-g on the single unlocked display always returns things to
normal, but finding that display is not always easy.)

Multi-tty users stumble upon these bugs quite frequently (e.g. `emacs
-f server-start' is a popular alias).  I attached a patch (adapted
from emacs--multi-tty--0--patch-189) that clears single_kboard each
time Emacs returns to top-level.  This seems to fix both bugs:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: single_kboard.patch --]
[-- Type: text/x-patch, Size: 456 bytes --]

*** orig/src/keyboard.c
--- mod/src/keyboard.c
***************
*** 1247,1252 ****
--- 1247,1256 ----
      while (1)
        {
  	internal_catch (Qtop_level, top_level_1, Qnil);
+         /* Reset single_kboard in case top-level set it while
+            evaluating an -f option, or we are stuck there for some
+            other reason. */
+         any_kboard_state ();
  	internal_catch (Qtop_level, command_loop_2, Qnil);
  	executing_macro = Qnil;
  

[-- Attachment #3: Type: text/plain, Size: 997 bytes --]


A possible third bug (and a definite inconvenience) is that entering a
recursive edit (M-x recursive-edit) or a debug session like above sets
single_kboard.  Pressing C-g unfreezes the other keyboards without
exiting the recursion, with no apparent bad side effects.  The bug is
either that the displays are frozen unnecessarily, or that C-g should
not break out of single_kboard in this case.  (I hope the former, but
verifying (or fixing) this is hard for me.) :-)

(By the way, sometimes single_kboard is very annoying even when it
works right: accidentally leaving an active minibuffer on one display
freezes all others, with no way to awaken them without access to the
display that caused the lockup.  It would be nice if Emacs could
always accept input from each keyboard.  But if that's not possible, I
think it should at least provide some feedback when the user presses a
key on the "wrong" display, and maybe allow C-g to work on frozen
displays. WDYT?)

-- 
Károly

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2004-07-16 16:08 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-07  7:45 Emacs routinely gets stuck in single_kboard mode Lőrentey Károly
2004-06-13 21:49 ` Richard Stallman
2004-07-11  1:29   ` Lőrentey Károly
2004-07-11  3:55     ` Lőrentey Károly
2004-07-11 23:23       ` Richard Stallman
2004-07-12 23:58         ` Richard Stallman
2004-07-13 16:55           ` Lőrentey Károly
2004-07-11 23:23     ` Richard Stallman
2004-07-12  6:18       ` Lőrentey Károly
2004-07-12 23:57         ` Richard Stallman
2004-07-13 17:12           ` Lőrentey Károly
2004-07-13 23:49             ` David Kastrup
2004-07-14 18:26             ` Richard Stallman
2004-07-15 22:22               ` Lőrentey Károly
2004-07-16 16:08                 ` Richard Stallman

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.