* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
@ 2009-01-21 23:02 Adrian Robert
2009-02-06 18:26 ` poppyer
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Robert @ 2009-01-21 23:02 UTC (permalink / raw)
To: 1578; +Cc: poppyer
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
2009-01-21 23:02 bug#1578: emacsclient -c make emacs very slow (under Mac OSX) Adrian Robert
@ 2009-02-06 18:26 ` poppyer
2009-02-07 10:37 ` Adrian Robert
0 siblings, 1 reply; 6+ messages in thread
From: poppyer @ 2009-02-06 18:26 UTC (permalink / raw)
To: Adrian Robert; +Cc: 1578
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
2009-02-06 18:26 ` poppyer
@ 2009-02-07 10:37 ` Adrian Robert
2009-02-07 15:26 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Adrian Robert @ 2009-02-07 10:37 UTC (permalink / raw)
To: poppyer; +Cc: 1578
On Feb 6, 2009, at 8:26 PM, poppyer wrote:
> 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.
This a good idea and would probably meet better with user
expectations when the only frame is closed (get rid of the icon in
the dock), also applicable when started with --daemon.
I don't have time to work on it right now, so if someone else wants
to take a crack.. it shouldn't be that hard (though there could be
unexpected gotchas I guess)...
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
2009-02-07 10:37 ` Adrian Robert
@ 2009-02-07 15:26 ` Stefan Monnier
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2009-02-07 15:26 UTC (permalink / raw)
To: Adrian Robert; +Cc: poppyer, 1578
>> 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.
> This a good idea and would probably meet better with user expectations when
> the only frame is closed (get rid of the icon in the dock), also applicable
> when started with --daemon.
> I don't have time to work on it right now, so if someone else wants to take
> a crack.. it shouldn't be that hard (though there could be unexpected
> gotchas I guess)...
Odd: I'm not a regular Mac OS X user, but from the little bit of
exposure I've had to this system, I would have expected the exact
opposite: I'd have expected "emacs --daemon" to bring up the Emacs icon
in the dock even before the first frame is opened, and would stay there
until the daemon exits.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
2008-12-14 3:55 bug#1578: 23.0.60; [EmacsCarbon] " poppyer
@ 2016-03-06 3:38 ` Hagmonk
2016-03-26 2:32 ` Andrew Hyatt
0 siblings, 1 reply; 6+ messages in thread
From: Hagmonk @ 2016-03-06 3:38 UTC (permalink / raw)
To: 1578
I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.
nsterm.m has been reworked somewhat over the past 6 years, including ns_read_socket which I believe is the function in question based on the conditional it used to have to check whether it was “inNsSelect”.
I’d suggest returning this to the reporter for verification.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
2016-03-06 3:38 ` bug#1578: " Hagmonk
@ 2016-03-26 2:32 ` Andrew Hyatt
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Hyatt @ 2016-03-26 2:32 UTC (permalink / raw)
To: Hagmonk; +Cc: 1578
Seeing how this was marked unreproducible for a few weeks now, I'm going
to close this out. Someone can re-open if it still can reproduce on Emacs
25.
Hagmonk <hagmonk@icloud.com> writes:
> I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.
>
> nsterm.m has been reworked somewhat over the past 6 years, including
> ns_read_socket which I believe is the function in question based on the
> conditional it used to have to check whether it was “inNsSelect”.
>
> I’d suggest returning this to the reporter for verification.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-26 2:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-21 23:02 bug#1578: emacsclient -c make emacs very slow (under Mac OSX) Adrian Robert
2009-02-06 18:26 ` poppyer
2009-02-07 10:37 ` Adrian Robert
2009-02-07 15:26 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2008-12-14 3:55 bug#1578: 23.0.60; [EmacsCarbon] " poppyer
2016-03-06 3:38 ` bug#1578: " Hagmonk
2016-03-26 2:32 ` Andrew Hyatt
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.