[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?
Ken