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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Tue, 8 Sep 2015 06:15:47 -0400
> Cc: 11822@debbugs.gnu.org
> 
> > The face cache of a new frame should start out empty, so clearing it
> > is a no-op.  But maybe you mean something else, I didn't yet have a
> > good look at the backtraces.
> 
> Since there’s nothing to clear out on that frame, there should be no need to make the call. But we make it, and the call we make forces the clearing of all caches, not just the one for that frame.

Therefore, we should prevent the effect of that on other frames.  I
see no need for this effect, since faces are frame-local.

> > The face cache is per-frame, so indeed, there should be no effect on
> > other frames.  If the backtraces indicate otherwise, I'd be surprised.
> 
> Unfortunately Fclear_face_cache (and global variables like face_change_count or windows_or_buffers_changed) isn’t frame-specific. So — I expect but haven’t tested — changing screenGamma on an existing frame will probably also force faces to be recomputed on every frame.

Then we should make them part of the frame structure, and only clear
the face cache of a single frame at a time -- the frame on which a
change to faces requires that.

> >> 5) Even better, can we do the other-display updates in small increments, so that once we start doing those updates we don’t have a block of 160*RTT seconds where we’re unresponsive to new user input?
> > 
> > Not sure I understand the idea; please elaborate about the increments
> > you had in mind.
> 
> In realize_basic_faces we call realize_named_face 14 times and realize_default_face once. For a display that’s not the one the user appears to be using (selected frame is elsewhere, no X events received), I’m wondering if we can have Emacs check for events (user input on any frame, subprocess output, etc), if there are none, realize one face, check for events again, etc., and when all of the faces are done, do any needed updates to the frame. Give priority to user interaction as much as possible, both in terms of handling input events and prioritizing updates to certain frames over others. Of course, if we get events associated with that other frame/display, or a call is made to force redisplay, we’d want to get things updated right away.

I'm still not following you: what do input events have to do with the
need to redisplay or not redisplay some frame(s)?

> That’s probably a lot of work. :-) But maybe there are some smaller changes that could be made. Do we have to realize all 15 right away?

The way the code is written, it expects the basic faces to be
realized, yes.

> If it’s not the selected frame, perhaps it doesn’t need the (active) mode line face

As you see from your backtraces, Emacs changes the selected frame many
times behind your back, so this is not true.

Anyway, I think preventing frames from being unnecessarily redisplayed
will bring larger benefits than just avoiding realization of some
faces.

> and if there are no tool bar or scroll bars, it doesn’t need those faces either. Maybe they could be processed later as (or if) needed?

We would need flags to manage that.  Once again, I don't think the
basic faces are the main problem as long as they are rtealized only
for the frame(s) that really need them to be recomputed.