[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Raeburn
Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text
Date: Fri, 10 Aug 2012 03:27:04 -0400

On Aug 10, 2012, at 02:16, Eli Zaretskii wrote:
> 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.

Ah, that's interesting.  It's especially interesting considering I have menu 
bar and tool bar displays turned off.  The one frame (X11 window) I have on the 
remote display is subdivided into four Emacs windows (top vs bottom, then each 
of those split into left and right).  And there's the minibuffer, of course.  
Currently three of those four windows have header lines, but there is no tool 
bar or 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?

I haven't really looked at the redisplay code much, but shouldn't a cache be, I 
don't know, caching this stuff it keeps looking up over and over?  According to 
the code you quoted, it's a "face cache", and all I see is color-processing 
calls, but if we're not building faces, why do we need the color processing, 
and if we are building them, why aren't we caching them?

Oh, hmm… the code you quoted ensures that the indicated frame has a face cache, 
and conditionally calls recompute_basic_faces; that function checks that there 
is a face cache, and if so, calls clear_face_cache and then 
realize_basic_faces.  But clear_face_cache clears caches of all frames.  So if 
I understand correctly, if that function you quoted (init_iterator) is given a 
frame with no cache (which I assume is the state a new frame is in?), or if the 
cache "used" flag is clear, it'll wipe out all cached faces from all frames, so 
the higher-level iteration over all the frames (or windows?) will have to 
rebuild the faces, even if they had indeed been cached.  Is that correct?

Is there a reason recompute_basic_faces can't just clear the cache for its own 
frame and leave the others alone?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]