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

[Ovidiu Gheorghioiu <ovy@alum.mit.edu>]

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