[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
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, (continued)
- Re: Emacs routinely gets stuck in single_kboard mode, Richard Stallman, 2004/07/11
- Re: Emacs routinely gets stuck in single_kboard mode, Lőrentey Károly, 2004/07/12
- Re: Emacs routinely gets stuck in single_kboard mode, Richard Stallman, 2004/07/12
- Re: Emacs routinely gets stuck in single_kboard mode, Lőrentey Károly, 2004/07/13
- Re: Emacs routinely gets stuck in single_kboard mode, David Kastrup, 2004/07/13
- Re: Emacs routinely gets stuck in single_kboard mode, Richard Stallman, 2004/07/14
- Re: Emacs routinely gets stuck in single_kboard mode,
Lőrentey Károly <=
- Re: Emacs routinely gets stuck in single_kboard mode, Richard Stallman, 2004/07/16