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

[Eli Zaretskii]

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