Emacs routinely gets stuck in single_kboard mode

Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

[-- 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

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    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.

A recursive edit or debug session must set single_kboard,
because the environment of the recursive edit or debug session
would otherwise be imposed on all the other terminals.

This is part of the reason why we discourage use of recursive edit.
It cannot be avoided unless we implement multi-threading in Emacs.


Does this fix that bug?

*** keyboard.c	11 Jun 2004 21:54:28 -0400	1.778
--- keyboard.c	13 Jun 2004 16:19:43 -0400	
***************
*** 1158,1164 ****
  
    Vinhibit_quit = Qnil;
  #ifdef MULTI_KBOARD
!   any_kboard_state ();
  #endif
  
    return make_number (0);
--- 1158,1165 ----
  
    Vinhibit_quit = Qnil;
  #ifdef MULTI_KBOARD
!   if (command_loop_level == 0 && minibuf_level == 0)
!     any_kboard_state ();
  #endif
  
    return make_number (0);

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Sorry for the long response time!

Richard Stallman <rms@gnu.org> writes:
>     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.
>
> A recursive edit or debug session must set single_kboard,
> because the environment of the recursive edit or debug session
> would otherwise be imposed on all the other terminals.

I see, but if there are multiple frames, then that recursive
environment is imposed on them, and AFAICS in that case this only
results in some small inconveniences that are easy to work around.  I
have only seen exactly these same effects when C-g exited
single_kboard, no new bugs.  So why are multiple displays different
from frames in this particular case?  Did I miss some important edge
case in the implementation?  Input event processing in Emacs is still
a hazy area for me.

By the way, the biggest such inconvenience I have found is a small
wrinkle that appears when I forget about a minibuffer prompt and
switch to another frame.  It is reproducible in the CVS trunk, too:

    emacs -q --eval '(setq enable-recursive-minibuffers t)'
    	C-x 5 2
        <First frame> C-x C-f
        <Second frame> M-x
        	(Note that the cursor in the first frame returns to
                 the *scratch* buffer's window)
        <Second frame> C-g

At this point, the C-x C-f prompt is still there in the minibuffer,
but the minibuffer window is active in neither frame.  What is more,
pressing C-x o to return to the minibuffer to finish (or cancel) the
command only works in the second frame, not in the first where it was
initiated.  (I seem to remember that Emacs 19/20 behaved more
intuitively, but I am not able to test that now.)

> This is part of the reason why we discourage use of recursive edit.
> It cannot be avoided unless we implement multi-threading in Emacs.
>
> Does this fix that bug?

Yes, the patch does prevent C-g from unfreezing the other displays.

> *** keyboard.c	11 Jun 2004 21:54:28 -0400	1.778
> --- keyboard.c	13 Jun 2004 16:19:43 -0400	
> ***************
> *** 1158,1164 ****
>   
>     Vinhibit_quit = Qnil;
>   #ifdef MULTI_KBOARD
> !   any_kboard_state ();
>   #endif
>   
>     return make_number (0);
> --- 1158,1165 ----
>   
>     Vinhibit_quit = Qnil;
>   #ifdef MULTI_KBOARD
> !   if (command_loop_level == 0 && minibuf_level == 0)
> !     any_kboard_state ();
>   #endif
>   
>     return make_number (0);

-- 
Károly

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Lőrentey Károly <lorentey@elte.hu> writes:
> Richard Stallman <rms@gnu.org> writes:
>> Does this fix that bug?
>
> Yes, the patch does prevent C-g from unfreezing the other displays.

Unfortunately having single_kboard enabled during a recursive edit
allows me to permanently lock myself out of my Emacs session, as I
have discovered by accident a few minutes ago. :-(

Try this with today's CVS trunk:

        $ ssh -X localhost      # Create an alias for the current display
          $ echo $DISPLAY
	  localhost:10.0  (or whatever)
          $

        Then, from another terminal:

	$ emacs -q --no-site-file
        M-x make-frame-on-display <RET> localhost:10.0 <RET>
        	# A new frame is created
        M-x recursive-edit
                # The other frame is locked
        C-x 5 0
                # Ooops

After I delete the frame that has the recursive-edit running, Emacs
has only a single locked frame, with no way to unlock it, unless the
Emacs server was started earlier.

Worse, killing the X display by closing the ssh session causes Emacs to
abort with the following backtrace:

#0  0x410ea1f1 in kill () from /lib/tls/libc.so.6
#1  0x080edc11 in fatal_error_signal (sig=17740) at src/emacs.c:395
#2  <signal handler called>
#3  0x410ea1f1 in kill () from /lib/tls/libc.so.6
#4  0x080edc6c in abort () at src/emacs.c:428
#5  0x080f07c4 in cmd_error_internal (data=145476189, context=0xbfffe980 "") at src/keyboard.c:1185
#6  0x080f0709 in cmd_error (data=0) at src/keyboard.c:1155
#7  0x08153f69 in internal_condition_case (bfun=0x80f0b90 <command_loop_1>, handlers=138382865, hfun=0x80f0650 <cmd_error>) at src/eval.c:1325
#8  0x080f09be in command_loop_2 () at src/keyboard.c:1278
#9  0x08153afb in internal_catch (tag=0, func=0x80f0990 <command_loop_2>, arg=138321937) at src/eval.c:1096
#10 0x080f08fe in command_loop () at src/keyboard.c:1245
#11 0x080f03d4 in recursive_edit_1 () at src/keyboard.c:963
#12 0x080f0511 in Frecursive_edit () at src/keyboard.c:1024
#13 0x08155daf in Ffuncall (nargs=1, args=0xbfffed44) at src/eval.c:2725
#14 0x081515b4 in Fcall_interactively (function=138376513, record_flag=17290248, keys=138378796) at src/callint.c:862
#15 0x080fc6fc in Fcommand_execute (cmd=138376513, record_flag=138321985, keys=0, special=0) at src/keyboard.c:9696
#16 0x080fca49 in Fexecute_extended_command (prefixarg=138321937) at src/keyboard.c:9793
#17 0x08155dbf in Ffuncall (nargs=2, args=0xbffff064) at src/eval.c:2728
#18 0x081515b4 in Fcall_interactively (function=138379217, record_flag=17290242, keys=138378796) at src/callint.c:862
#19 0x080fc6fc in Fcommand_execute (cmd=138379217, record_flag=138321937, keys=0, special=0) at src/keyboard.c:9696
#20 0x080f0f4e in command_loop_1 () at src/keyboard.c:1748
#21 0x08153fbe in internal_condition_case (bfun=0x80f0b90 <command_loop_1>, handlers=138382865, hfun=0x80f0650 <cmd_error>) at src/eval.c:1335
#22 0x080f09be in command_loop_2 () at src/keyboard.c:1278
#23 0x08153afb in internal_catch (tag=0, func=0x80f0990 <command_loop_2>, arg=138321937) at src/eval.c:1096
#24 0x080f0963 in command_loop () at src/keyboard.c:1257
#25 0x080f03d4 in recursive_edit_1 () at src/keyboard.c:963
#26 0x080f0511 in Frecursive_edit () at src/keyboard.c:1024
#27 0x080eec40 in main (argc=1, argv=0xbffff8f4) at src/emacs.c:1687

-- 
Károly

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    > A recursive edit or debug session must set single_kboard,
    > because the environment of the recursive edit or debug session
    > would otherwise be imposed on all the other terminals.

    I see, but if there are multiple frames, then that recursive
    environment is imposed on them, and AFAICS in that case this only
    results in some small inconveniences that are easy to work around.

Sorry, I don't follow what you're saying here.
The other terminals won't see the buffer that the recursive
edit or debug session is in, and there is potential
for a lot of confusion.

	emacs -q --eval '(setq enable-recursive-minibuffers t)'
	    C-x 5 2
	    <First frame> C-x C-f
	    <Second frame> M-x
		    (Note that the cursor in the first frame returns to
		     the *scratch* buffer's window)
	    <Second frame> C-g

    At this point, the C-x C-f prompt is still there in the minibuffer,

In which frame?

    but the minibuffer window is active in neither frame.

Exiting the minibuffer ought to erase it wherever it is.
But this does not exit the C-x C-f minibuffer.  I can go to
the frame where it appears, type C-x o, enter a file name,
and visit the file.

However, things are screwed up in some other way after that.
I find the minibuffer being displayed in both frames at once.

Would someone like to debug this?

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    After I delete the frame that has the recursive-edit running, Emacs
    has only a single locked frame, with no way to unlock it, unless the
    Emacs server was started earlier.

Killing the sole frame on a certain display should exit single_kboard mode
if it is enabled on tht display.

Would someone like to implement that?

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Richard Stallman <rms@gnu.org> writes:
>     > A recursive edit or debug session must set single_kboard,
>     > because the environment of the recursive edit or debug session
>     > would otherwise be imposed on all the other terminals.
>
>     I see, but if there are multiple frames, then that recursive
>     environment is imposed on them, and AFAICS in that case this only
>     results in some small inconveniences that are easy to work around.
>
> Sorry, I don't follow what you're saying here.
> The other terminals won't see the buffer that the recursive
> edit or debug session is in, and there is potential
> for a lot of confusion.

I agree, but I think locking up the other displays leads to even more
problems.  Having a debug window hidden on another display (or while
we are at it, on another frame) is confusing, but at least I can use
C-M-c or C-] to return to sanity from everywhere.  On the other hand,
having a whole display completely locked up with no indication of what
happened, and no way to unlock without switching to another display is
guaranteed to confuse and annoy me.

Here is an example: Let's say I log in to my office workstation from
home, and start up an Emacs display on my remote X server via
emacsclient.  Suppose that I was careless, and before I went home I
somehow left my Emacs inside a recursive edit.  In this case,
emacsclient will succeed to create a new frame on the remote server,
but the frame will not accept any input, not even a delete-frame event
from the window manager, until I go back to my office to press C-]. :-(

-- 
Károly

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    > Sorry, I don't follow what you're saying here.
    > The other terminals won't see the buffer that the recursive
    > edit or debug session is in, and there is potential
    > for a lot of confusion.

    I agree, but I think locking up the other displays leads to even more
    problems.

Maybe it should display something saying "Locked by another keyboard"
in all the windows for other keyboards.  That way, the person at that
keyboard will understand why it is locked.

You seem to be envisioning that there is only one user, who uses
the various different keyboards.  I've always thought in terms of
a different user at each keyboard.  Perhaps this is why we have
different ideas of what would be desirable.

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    Killing the sole frame on a certain display should exit single_kboard mode
    if it is enabled on tht display.

    Would someone like to implement that?

I decided to write it rather than wonder if someone would.
Does this fix it?  Add the following function to keyboard.c
and install the patch below.


/* If we're in single_kboard state for kboard KBOARD,
   get out of it.  */

void
not_single_kboard_state (kboard)
     KBOARD *kboard;
{
  if (kboard == current_kboard)
    single_kboard = 0;
}


*** frame.c	16 Nov 2003 20:36:24 -0500	1.306
--- frame.c	12 Jul 2004 16:55:02 -0400	
***************
*** 1327,1332 ****
--- 1327,1362 ----
  	}
      }
  
+   /* If there's no other frame on the same kboard, get out of
+      single-kboard state if we're in it for this kboard.  */
+   {
+     Lisp_Object frames;
+     /* Some frame we found on the same kboard, or nil if there are none.  */
+     Lisp_Object frame_on_same_kboard;
+ 
+     frame_on_same_kboard = Qnil;
+ 
+     for (frames = Vframe_list;
+ 	 CONSP (frames);
+ 	 frames = XCDR (frames))
+       {
+ 	Lisp_Object this;
+ 	struct frame *f1;
+ 
+ 	this = XCAR (frames);
+ 	if (!FRAMEP (this))
+ 	  abort ();
+ 	f1 = XFRAME (this);
+ 
+ 	if (FRAME_KBOARD (f) == FRAME_KBOARD (f1))
+ 	  frame_on_same_kboard = this;
+       }
+ 
+     if (NILP (frame_on_same_kboard))
+       not_single_kboard_state (FRAME_KBOARD (f));
+   }
+ 
+ 
    /* If we've deleted this keyboard's default_minibuffer_frame, try to
       find another one.  Prefer minibuffer-only frames, but also notice
       frames with other windows.  */

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Richard Stallman <rms@gnu.org> writes:
>     Killing the sole frame on a certain display should exit single_kboard mode
>     if it is enabled on tht display.
>
>     Would someone like to implement that?
>
> I decided to write it rather than wonder if someone would.
> Does this fix it?

Yes, it does fix the problem.

-- 
Lőrentey Károly

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Richard Stallman <rms@gnu.org> writes:
> Maybe it should display something saying "Locked by another keyboard"
> in all the windows for other keyboards.  That way, the person at that
> keyboard will understand why it is locked.

That is a good compromise; I'll have a go at implementing it.

> You seem to be envisioning that there is only one user, who uses
> the various different keyboards.  I've always thought in terms of
> a different user at each keyboard.  Perhaps this is why we have
> different ideas of what would be desirable.

Ah, I see.  I agree that if there are multiple users, then an unlocked
recursive edit would probably mess things up pretty badly.  Anyway, I
found that while the Emacs server is running (which is likely to be
the case when there are multiple displays), the following trick may be
used to remotely bail out of a forgotten recursive edit:

	emacsclient -e '(top-level)'

(Emacsclient needs to be killed with C-c after this.)

(Incidentally, this calls top-level from a process filter.  Is that
supported?)

-- 
Károly

Re: Emacs routinely gets stuck in single_kboard mode

[David Kastrup]

lorentey@elte.hu (Lőrentey Károly) writes:

> Anyway, I found that while the Emacs server is running (which is
> likely to be the case when there are multiple displays), the
> following trick may be used to remotely bail out of a forgotten
> recursive edit:
> 
> 	emacsclient -e '(top-level)'
> 
> (Emacsclient needs to be killed with C-c after this.)

You could call emacsclient with the --no-wait option.

> (Incidentally, this calls top-level from a process filter.  Is that
> supported?)

No idea, but it gives me the creeps.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

    (Incidentally, this calls top-level from a process filter.  Is that
    supported?)

It should be.

It could make sense to offer some way to unlock single-keyboard state
from another keyboard, as long as it is something that people won't be
likely to do without intending this effect.  It can't be mere C-g,
because people are likely to type C-g without realizing the situation
they are in.  Can you think of a good interface?

Perhaps there could be a specific menu bar command that would do this.
People would not be likely to push that by accident, especially if it
leads to a submenu containing the item "Confirm and Proceed" before
you really issue the command.

Re: Emacs routinely gets stuck in single_kboard mode

[Lőrentey Károly]

Richard Stallman <rms@gnu.org> writes:
> It could make sense to offer some way to unlock single-keyboard state
> from another keyboard, as long as it is something that people won't be
> likely to do without intending this effect.  It can't be mere C-g,
> because people are likely to type C-g without realizing the situation
> they are in.  Can you think of a good interface?
>
> Perhaps there could be a specific menu bar command that would do this.
> People would not be likely to push that by accident, especially if it
> leads to a submenu containing the item "Confirm and Proceed" before
> you really issue the command.

Well, that solution would work, but only if the menu bar is enabled.
Also, I think it would be hard to adapt it to work on termcap
displays.  Naturally, that is not an issue in current Emacs CVS, but I
would prefer a solution that would continue to work after the
multi-tty merge.  The problem is that as far as I know, the menu can
not be activated from a locked termcap keyboard.  (I wonder if porting
the DOS port's menu interface to termcap displays would help with
this.)

What if 1) each blocked keyboard event would put something like the
following message in the echo area of the frame it came from:

	Please wait; this keyboard is locked by activity on the foobar:0 display

and 2) pressing C-g would pop up a (faked?) y-or-n-p with a variation
of the following prompt (but better worded):

	Break the lock?  (Warning, the effects may be unexpected) (y or n)

Pressing C-g again would cancel the prompt and leave Emacs in
single-keyboard state, so the user would not accidentally break the
lock.  Pressing y would unlock single-keyboard and warn the user again
about the remote recursive edit.

I suspect this solution would not be trivial to implement (there are
several interesting corner cases), but I think it would be very easy
for the user to understand.

What do you think?


(By the way, I guess implementing point 1 above is enough for the next
release.  Built-in support for exiting the single-keyboard state from
another display should perhaps be left off for Emacs 22, or whenever
the multi-tty branch gets merged into CVS.  Especially if we choose
something like this C-g-based approach.)

-- 
Károly

Re: Emacs routinely gets stuck in single_kboard mode

[Richard Stallman]

	    Please wait; this keyboard is locked by activity on the foobar:0 display

    and 2) pressing C-g would pop up a (faked?) y-or-n-p with a variation
    of the following prompt (but better worded):

	    Break the lock?  (Warning, the effects may be unexpected) (y or n)

    Pressing C-g again would cancel the prompt and leave Emacs in
    single-keyboard state, so the user would not accidentally break the
    lock.

I think that is not hard enough to do by accident.  It would
cause problems.

How about if it displays one message, discards all input, displays
another message, then asks for input?  That could be harder to do by
accident.  Maybe it could even discard input twice, separated by one
second?