From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Thu, 09 Aug 2012 17:12:50 -0400 Message-ID: <502427D2.3080003@permabit.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344546841 25340 80.91.229.3 (9 Aug 2012 21:14:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Aug 2012 21:14:01 +0000 (UTC) To: 11822@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 09 23:14:01 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 1Sza3I-0005uP-1n for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Aug 2012 23:13:56 +0200 Original-Received: from localhost ([::1]:44026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sza3H-0002Rx-56 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Aug 2012 17:13:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sza3E-0002Rq-AZ for bug-gnu-emacs@gnu.org; Thu, 09 Aug 2012 17:13:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sza3C-0002Kw-Hf for bug-gnu-emacs@gnu.org; Thu, 09 Aug 2012 17:13:52 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sza3C-0002Ks-DU for bug-gnu-emacs@gnu.org; Thu, 09 Aug 2012 17:13:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SzaB7-0005R6-N0 for bug-gnu-emacs@gnu.org; Thu, 09 Aug 2012 17:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Aug 2012 21:22: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.134454726620825 (code B ref 11822); Thu, 09 Aug 2012 21:22:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 9 Aug 2012 21:21:06 +0000 Original-Received: from localhost ([127.0.0.1]:45344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzaAE-0005Pp-66 for submit@debbugs.gnu.org; Thu, 09 Aug 2012 17:21:06 -0400 Original-Received: from pbit-mailserver.permabit.com ([204.246.225.83]:59549) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzaAB-0005Ph-7N for 11822@debbugs.gnu.org; Thu, 09 Aug 2012 17:21:04 -0400 Original-Received: from just-testing.permabit.com (just-testing.permabit.com [10.95.208.54]) by pbit-mailserver.permabit.com (Postfix) with ESMTP id 12603148E1E4; Thu, 9 Aug 2012 17:12:51 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120317 Icedove/3.0.11 In-Reply-To: <415962DC-9BF5-4595-8180-7BE8DB545206@permabit.com> 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:62977 Archived-At: 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: Breakpoint 3, recompute_basic_faces (f=0x4d75e00) at xfaces.c:835 835 { (gdb) c Continuing. Breakpoint 3, recompute_basic_faces (f=0x4d75e00) at xfaces.c:835 835 { (gdb) Continuing. Breakpoint 3, recompute_basic_faces (f=0x4d75e00) at xfaces.c:835 835 { (gdb) Continuing. Breakpoint 3, recompute_basic_faces (f=0x61a7090) at xfaces.c:835 835 { (gdb) Continuing. Breakpoint 3, recompute_basic_faces (f=0x698a7c0) at xfaces.c:835 835 { (gdb) Continuing. ... I also noticed that the remote frame (in this case, 0x52fff50, which happens to be the one shown in the C stack trace above, is displayed over SSH + VPN + a slow net connection) takes quite a bit longer to process before moving on to the next recompute_basic_faces call. I've been using this Emacs process actively today, including creating a few new frames, but haven't touched the frame displayed remotely since at least last night, possibly longer. Yet this recompute_basic_faces work still gets done each time. If I try creating a new tty frame, the stack trace is a bit different: #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 0x00007fa62a08fb11 in XParseColor () from /usr/lib/libX11.so.6 #5 0x00000000004cafa4 in x_defined_color (f=0x52fff50, color_name=, color=0x7fff726fe430, alloc_p=1) at xfns.c:611 #6 0x00000000004a9adc in load_color (f=0x7fff726fe210, face=0x4b738f0, name=102599489, target_index=LFACE_BACKGROUND_INDEX) at xfaces.c:1336 #7 0x00000000004abc38 in load_face_colors (attrs=, face=, f=) at xfaces.c:1421 #8 realize_x_face (attrs=, cache=) at xfaces.c:5629 #9 realize_face (cache=0x3e3ec30, attrs=0x7fff726fe5a0, former_face_id=) at xfaces.c:5501 #10 0x00000000004b0eed in realize_named_face (f=, symbol=, id=10) at xfaces.c:5473 #11 0x00000000004b1181 in realize_basic_faces (f=0x52fff50) at xfaces.c:5298 #12 0x00000000004b17cd in recompute_basic_faces (f=0x52fff50) at xfaces.c:839 #13 0x000000000043938d in init_iterator (it=0x7fff726fe7a0, w=0x56d0850, charpos=-1, bytepos=-1, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2618 #14 0x000000000044962b in x_consider_frame_title (frame=) at xdisp.c:10972 #15 0x0000000000449774 in prepare_menu_bars () at xdisp.c:11031 #16 0x0000000000455b95 in redisplay_internal () at xdisp.c:12944 #17 0x0000000000503359 in read_char (commandflag=, nmaps=, maps=0x0, prev_event=, used_mouse_menu=, end_time=) at keyboard.c:2448 #18 0x000000000059416c in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_method=0, seconds=) at lread.c:621 #19 0x000000000056c9d9 in Ffuncall (nargs=, args=) at eval.c:3009 #20 0x00000000005a6ef5 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=104812360, args=0x33a5) at bytecode.c:785 ... Lisp Backtrace: "read-event" (0x727014a8) "terminal-init-xterm" (0x72701688) "tty-run-terminal-initialization" (0x72701848) "tty-create-frame-with-faces" (0x72701a08) "make-frame" (0x72701bf0) "server-create-tty-frame" (0x72701df0) 0x5f64d20 PVEC_COMPILED ... 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. That seems to be where the delay is coming from. If, in fact, the Lisp code supporting the xterm type is sending its escape sequence before all of this is triggered, that would certainly explain why it times out and the response sequence winds up added to the buffer content. Ken