bug#1578: 23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)

bug#1578: 23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)

[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)




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]

bug#1578: emacsclient -c make emacs very slow (under Mac OSX)

[Hagmonk]

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.

bug#1578: emacsclient -c make emacs very slow (under Mac OSX)

[Andrew Hyatt]

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.