From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Fri, 10 Aug 2012 09:16:45 +0300 Message-ID: <83ipcre0fm.fsf@gnu.org> References: <6eipe9fypj.fsf@just-testing.permabit.com> <83d34h739a.fsf@gnu.org> <501848BE.10702@permabit.com> <5021D940.8050401@permabit.com> <415962DC-9BF5-4595-8180-7BE8DB545206@permabit.com> <502427D2.3080003@permabit.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1344579420 11628 80.91.229.3 (10 Aug 2012 06:17:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 06:17:00 +0000 (UTC) Cc: 11822@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 10 08:17:00 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SziWm-0000eD-OO for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 08:16:56 +0200 Original-Received: from localhost ([::1]:60597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SziWl-00014z-U3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Aug 2012 02:16:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SziWh-00014q-P1 for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 02:16:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SziWf-0006bo-73 for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 02:16:51 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SziWf-0006bh-2D for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 02:16:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sziec-00029n-2e for bug-gnu-emacs@gnu.org; Fri, 10 Aug 2012 02:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Aug 2012 06:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11822 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11822-submit@debbugs.gnu.org id=B11822.13445798988280 (code B ref 11822); Fri, 10 Aug 2012 06:25:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 10 Aug 2012 06:24:58 +0000 Original-Received: from localhost ([127.0.0.1]:45847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzieX-00029V-Sc for submit@debbugs.gnu.org; Fri, 10 Aug 2012 02:24:58 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:41496) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzieV-00029I-1r for 11822@debbugs.gnu.org; Fri, 10 Aug 2012 02:24:56 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M8J00500033L300@a-mtaout23.012.net.il> for 11822@debbugs.gnu.org; Fri, 10 Aug 2012 09:16:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8J0054003RDC90@a-mtaout23.012.net.il>; Fri, 10 Aug 2012 09:16:39 +0300 (IDT) In-reply-to: <502427D2.3080003@permabit.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62986 Archived-At: > Date: Thu, 09 Aug 2012 17:12:50 -0400 > From: Ken Raeburn > > I've chased the sluggishness down a little further. > > I'm using > > emacsclient -c -a "" -n > > to pop up a new frame. > > If I attach the Emacs process under GDB during the delay while I wait > for the new frame to be fully displayed, the call stack tends to look > like this: > > #0 0x00007fa626cc18d8 in poll () from /lib/libc.so.6 > #1 0x00007fa6265d98ca in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007fa6265dbc0c in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 > #3 0x00007fa62a0a7613 in _XReply () from /usr/lib/libX11.so.6 > #4 0x00007fa62a0831a5 in XAllocColor () from /usr/lib/libX11.so.6 > #5 0x00000000004b621c in x_alloc_nearest_color_1 (dpy=0x7fff726fdc40, > cmap=1, color=0xffffffffffffffff) at xterm.c:1730 > #6 0x00000000004cb023 in x_defined_color (f=0x52fff50, > color_name=, color=0x7fff726fde70, alloc_p=1) at xfns.c:613 > #7 0x00000000004a9adc in load_color (f=0x7fff726fdc40, face=0x53e7b70, > name=102599361, target_index=LFACE_FOREGROUND_INDEX) at xfaces.c:1336 > #8 0x00000000004abc53 in load_face_colors (attrs=, > face=, f=) at xfaces.c:1422 > #9 realize_x_face (attrs=, cache=) at > xfaces.c:5629 > #10 realize_face (cache=0x3e3ec30, attrs=0x7fff726fdfe0, > former_face_id=) at xfaces.c:5501 > #11 0x00000000004b0eed in realize_named_face (f=, > symbol=, id=7) at xfaces.c:5473 > #12 0x00000000004b1145 in realize_basic_faces (f=0x52fff50) at xfaces.c:5295 > #13 0x00000000004b17cd in recompute_basic_faces (f=0x52fff50) at > xfaces.c:839 > #14 0x000000000043938d in init_iterator (it=0x7fff726fe1e0, w=0x56d0850, > charpos=-1, bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at > xdisp.c:2618 > #15 0x000000000044962b in x_consider_frame_title (frame=) > at xdisp.c:10972 > #16 0x0000000000449774 in prepare_menu_bars () at xdisp.c:11031 > #17 0x0000000000455b95 in redisplay_internal () at xdisp.c:12944 > #18 0x0000000000456575 in redisplay_preserve_echo_area > (from_where=1919933504) at xdisp.c:13560 > #19 0x00000000005b3288 in Fdelete_process (process=69478117) at > process.c:796 > #20 0x000000000056c9fc in Ffuncall (nargs=, > args=) at eval.c:3002 > #21 0x00000000005a6ef5 in exec_byte_code (bytestr=, > vector=, maxdepth=, > args_template=, nargs=104812360, args=0x33a5) at > bytecode.c:785 > ... > > Lisp Backtrace: > "delete-process" (0x72700b50) > "server-delete-client" (0x72700ce0) > 0x4c33b60 PVEC_COMPILED > "funcall" (0x72700e40) > 0x4bde3c0 PVEC_COMPILED > "funcall" (0x72701260) > "server-execute" (0x727016b8) > 0x4e59700 PVEC_COMPILED > 0x4a72ac0 PVEC_COMPILED > "funcall" (0x72701970) > "server-execute-continuation" (0x72701de8) > ... > > Sometimes it's XParseColor instead of XAllocColor. > > When I pop up a new frame, it appears that recompute_basic_faces is > called three times for the new frame, and once for each existing one: Actually, recompute_basic_faces can be potentially called once for every _window_. That's because the GUI redisplay is window-based, i.e. it starts anew for every window that is visible. These calls come from here: /* If realized faces have been removed, e.g. because of face attribute changes of named faces, recompute them. When running in batch mode, the face cache of the initial frame is null. If we happen to get called, make a dummy face cache. */ if (FRAME_FACE_CACHE (it->f) == NULL) init_frame_faces (it->f); if (FRAME_FACE_CACHE (it->f)->used == 0) recompute_basic_faces (it->f); Normally, the frame's face cache is not removed during redisplay of frame's windows, so you get one call per frame. For new frames, the cache is empty, so you get 3 calls for each window on the new frame, which are: the frame's selected window, the menu bar, and the tool bar (the last two are displayed in a special kinds of window). For example, the backtrace above comes from displaying the menu bar. > But either way, we get into the display code and it thinks it's got to > do the color/face setup all over again for the remote display. If the face cache is empty, what else can it do?