* 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: 23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)
@ 2008-12-14 3:55 poppyer
2016-03-06 3:38 ` bug#1578: " Hagmonk
0 siblings, 1 reply; 6+ messages in thread
From: poppyer @ 2008-12-14 3:55 UTC (permalink / raw)
To: emacs-pretest-bug
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)
In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, NS apple-appkit-949.35)
of 2008-12-11 on neutron.local
Windowing system distributor `Apple', version 97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
configured using `configure '--with-ns''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: zh_CN.UTF-8
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Summary
Minor modes in effect:
gnus-agent-mode: t
erc-log-mode: t
erc-list-mode: t
erc-menu-mode: t
erc-autojoin-mode: t
erc-ring-mode: t
erc-networks-mode: t
erc-pcomplete-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-match-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-netsplit-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
iswitchb-mode: t
recentf-mode: t
which-function-mode: t
show-paren-mode: t
mouse-sel-mode: t
global-hl-line-mode: t
pinbar-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
RET ESC x n e w s C-p C-p RET q n n n n n p p RET SPC
n SPC C-n SPC n q p p RET C-n C-n C-n C-n C-n C-p C-p
C-p SPC SPC C-n SPC SPC C-n SPC c y p n n n n n n n
n n n n n p p p p p p p p p n n n n n p p p p p n n
n n n n p p p n n n p RET SPC q RET C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-p c y p p p p n RET SPC n n c y ESC [
B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC
[ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A
p n RET SPC q p RET SPC q p RET SPC SPC C-n SPC SPC
q C-c C-@ C-c C-@ C-c C-@ ESC 1 C-p C-p C-p C-p C-p
C-p ESC g n RET SPC n C-x 1 ESC x b DEL s u b TAB ESC
DEL ESC DEL e m TAB a TAB s u m i TAB TAB ESC DEL r
e TAB ESC DEL ESC DEL r e p o TAB r TAB e DEL TAB
RET
Recent messages:
Generating summary...done
Reading active file from gmail via nnimap...
nnimap: Checking mailboxes...done
Reading active file from freenews.netfront.net via nntp...
Checking new news...done
Retrieving newsgroup: nntp+freenews.netfront.net:cn.bbs.comp.emacs...
Fetching headers for nntp+freenews.netfront.net:cn.bbs.comp.emacs...done
Scoring...done
Generating summary...done
Making completion list... [2 times]
^ 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.