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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: raeburn@permabit.com,  11822@debbugs.gnu.org
> Date: Fri, 11 Sep 2015 08:56:58 -0400
> 
> >> >   /* Contrary to expectations, a value of "false" can be detrimental to
> >> >      responsiveness since aborting a redisplay throws away some of the
> >> >      work already performed.
> >> But that's because the effect was different from what is being
> >> discussed here (at least in theory): interrupting redisplay between
> >> windows wouldn't throw away work, AFAIK.
> > What Ken suggests is not an interruption between windows, it's
> > interruption in the middle of recomputing faces.  That's much worse.
> 
> I think he suggests several things.

Yes.  IMO, the discussion is not focused enough.

> Another is to do decompose the redisplay of a given window into
> chunks (e.g. cut at those points where we're waiting for a reply from
> the X server) that can be interrupted.  IIUC by "interrupted" he doesn't
> mean to abort what we're doing, but only to suspend it.

We don't have any infrastructure for suspending redisplay.

> What we need to remember from redisplay-dont-pause is that we need to
> avoid doing work and throwing it away before the result is shown on
> the display.  In the case of redisplay-dont-pause, the reason it's
> thrown away is that by the time we got back, the work we'd done
> (refreshing the matrices) often/usually needed to be redone.

Isn't that going to be the same with the proposed suspension?

> If we only interrupt after refreshing the display of a window and before
> starting to recompute the glyph matrices of the next, then I think we
> avoid this risk.

That would immediately exclude text-mode frames, where the updates are
always to the entire frame.

It would also exclude situations where more redisplaying a window
affects another window.  We will have to detect those cases somehow.

In short, I'm not sure this direction is worthy pursuing.  I think we
should first stop updating irrelevant frames due to face changes, and
then see about minimizing the color-related X calls when faces of a
frame do need to be recomputed.  All the rest can wait until after
that.