Re: Emacs hangs on current display when the minibuffer is active on another display

Re: Emacs hangs on current display when the minibuffer is active on another display

[Ovidiu Gheorghioiu]

Is there an eval forn that would cause emacs to exit this loop?

I can do gnuclient -eval from the display where Emacs is
non-functional. I've tried (keyboard-quit) and
(minibuffer-keyboard-quit) but that didn't work. Finally I did (setq
quit-flag t) with the -- foreseeable I guess -- result that Emacs quit
entirely. So maybe there is some hope. A workaround involving -eval
(something) would be perfectly acceptable for me.

Regards,
Ovy

On 9/27/06, Richard Stallman <rms@gnu.org> wrote:
>     If I leave the emacs on one
>     display with the minibuffer active, emacs on the other display does
>     not respond to anything until the minibuffer input is resolved (input
>     entered, or quit).
>
> It is nearly impossible to fix this without making Emacs
> multi-threaded.  I hope that will be done some day, but I
> don't know if anyone is working on it.
>
>

Re: Emacs hangs on current display when the minibuffer is active on another display

[Ovidiu Gheorghioiu]

FYI I've found a workaround for this old problem: I evaluate
'(abort-recursive-edit)' with gnuclient / emacsclient. Tested on emacs
23.1.1 and 22.1.1 (both of which still exhibit the
minibuffer-input-blocks-other-Xdisplay problem). This aborts the
minibuffer prompt, and lets me use emacs on the other display.

This is good enough for me.

Regards,
Ovy

> On Mon, Aug 20, 2007 at 8:54 PM, Ovidiu Gheorghioiu <ovy@alum.mit.edu> wrote:
> Is there an eval forn that would cause emacs to exit this loop?
>
> I can do gnuclient -eval from the display where Emacs is
> non-functional. I've tried (keyboard-quit) and
> (minibuffer-keyboard-quit) but that didn't work. Finally I did (setq
> quit-flag t) with the -- foreseeable I guess -- result that Emacs quit
> entirely. So maybe there is some hope. A workaround involving -eval
> (something) would be perfectly acceptable for me.
>
> Regards,
> Ovy
>
> On 9/27/06, Richard Stallman <rms@gnu.org> wrote:
>>     If I leave the emacs on one
>>     display with the minibuffer active, emacs on the other display does
>>     not respond to anything until the minibuffer input is resolved (input
>>     entered, or quit).
>>
>> It is nearly impossible to fix this without making Emacs
>> multi-threaded.  I hope that will be done some day, but I
>> don't know if anyone is working on it.
>>
>>
>

Re: Emacs hangs on current display when the minibuffer is active on another display

[Stefan Monnier]

> FYI I've found a workaround for this old problem: I evaluate
> '(abort-recursive-edit)' with gnuclient / emacsclient.  Tested on
> Emacs 23.1.1 and 22.1.1 (both of which still exhibit the
> minibuffer-input-blocks-other-Xdisplay problem).

This problem is supposed to be fixed in Emacs-23 already.
This is done in server-goto-toplevel.  If you still bump into the
problem, please report it as a bug.


        Stefan

Re: Emacs hangs on current display when the minibuffer is active on another display

[Johan Bockgård]

"Ovidiu Gheorghioiu" <ovy@alum.mit.edu> writes:

> Is there an eval forn that would cause emacs to exit this loop?
>
> I can do gnuclient -eval from the display where Emacs is
> non-functional. I've tried (keyboard-quit) and
> (minibuffer-keyboard-quit) but that didn't work. Finally I did (setq
> quit-flag t) with the -- foreseeable I guess -- result that Emacs quit
> entirely. So maybe there is some hope. A workaround involving -eval
> (something) would be perfectly acceptable for me.

(top-level)

I think emacsclient together with an up-to-date Emacs would to this
automatically.

-- 
Johan Bockgård