[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
From: |
poppyer |
Subject: |
bug#1578: emacsclient -c make emacs very slow (under Mac OSX) |
Date: |
Sat, 07 Feb 2009 02:26:50 +0800 |
User-agent: |
Emacs Gnus |
Adrian Robert <adrian.b.robert@gmail.com> writes:
>> First, I use emacs -nw to open a normal emacs in the terminal. Then I
>> use emacsclient -c to open a carbon frame. Now the terminal emacs
>> becomes very slow and unresponsive. (But the CPU is not running high).
>> Even after the carbon frame is closed, it is still same slow. (and I
>> have to close emacs and restart)
>
> This is because the events are being passed only after a full run
> through the NS event loop. See line 3194 in nsterm.m (the first one
> of ns_select()). Ideally this would drop down to the regular select
> () if the NS application ("carbon" frame) is not active. However, I
> haven't found a way to detect this without also causing the problem
> of failing to pick up the app becoming active again until after a
> long delay. I think the select() gets called with a long timeout
> and, no matter if cocoa-experimental-ctrl-g is set or not, no
> interruption of it happens.
>
> Since there is only one thread, an external call to, e.g. -
> applicationWillBecomeActive won't go through until after this select
> terminates.
I notice that if I start with "emacs -nw", there is no NSApp (no icon in
the osx dock). When I use "emacsclient -c" to open a NS frame, the icon
shows up. My idea here is, if I close every NS frame, can we destroy the
NSApp and make it nil again (say by testing the frame count) ? If this
is possible, it at least make emacsclient more usable; and I don't need
to restart Emacs.
Cheers,
poppyer
- bug#1578: emacsclient -c make emacs very slow (under Mac OSX),
poppyer <=