bug#11822: 24.1; emacsclient terminal mode captures escape characters as text

[Eli Zaretskii]

> Date: Thu, 09 Aug 2012 17:12:50 -0400
> From: Ken Raeburn <raeburn@permabit.com>
> 
> 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=<optimized out>, 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=<optimized out>, 
> face=<optimized out>, f=<optimized out>) at xfaces.c:1422
> #9  realize_x_face (attrs=<optimized out>, cache=<optimized out>) at 
> xfaces.c:5629
> #10 realize_face (cache=0x3e3ec30, attrs=0x7fff726fdfe0, 
> former_face_id=<optimized out>) at xfaces.c:5501
> #11 0x00000000004b0eed in realize_named_face (f=<optimized out>, 
> symbol=<optimized out>, 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=<optimized out>) 
> 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=<optimized out>, 
> args=<optimized out>) at eval.c:3002
> #21 0x00000000005a6ef5 in exec_byte_code (bytestr=<optimized out>, 
> vector=<optimized out>, maxdepth=<optimized out>, 
> args_template=<optimized out>, 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?