bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text
Date: Fri, 10 Aug 2012 10:46:23 +0300

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Fri, 10 Aug 2012 03:27:04 -0400
> Cc: 11822@debbugs.gnu.org
> 
> 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.

Not really relevant at this point, since the traceback shows Emacs was
displaying the frame title.

The code in prepare_menu_bars is computing the menu-bar items, it does
not display them.

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

It caches them when it can, AFAIK.  But I'm not the expert on that
part.

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

There are no colors in Emacs except as face attributes.  If you need
to colorize some parts of display, you need to realize a corresponding
face.

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

I think so, yes.

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

Are you saying that the used flag of the frame's cache is not a
sufficient condition for clearing the face caches?






reply via email to

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