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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Agreed, which I think is the more serious obstacle to this suggestion.

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

It could be, indeed.  Tho if we assume that modifications to
non-selected frames are infrequent and the suspension is only used
for the redisplay of the non-selected frame, then there's a good chance
that when we come back to the redisplay the suspended work can be
continued rather than having to start over.

In any case, as you pointed out above, allowing such suspension would
require a fair bit of work on the redisplay (and probably even in more
places).

My guess is that making redisplay concurrent (i.e. take place while the
main Elisp thread is running) won't be that much more work, and it'd
bring a lot more benefits.

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

Then replace "window" with "frame" above.

> It would also exclude situations where more redisplaying a window
> affects another window.

Hmmm... I don't know what you're referring to here.

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

100% agreement.


        Stefan