[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs routinely gets stuck in single_kboard mode

From: Lőrentey Károly
Subject: Re: Emacs routinely gets stuck in single_kboard mode
Date: Fri, 16 Jul 2004 00:22:57 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Richard Stallman <address@hidden> 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

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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]