Re: mouse-drag-and-drop-region

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 17 Nov 2017 17:44:02 -0500
> 
> > I don't see how this solves the problem, because the display engine
> > will still know nothing about that "second" matrix.
> 
> As mentioned: "it's this one which is then sent to be displayed", so
> this assumes we'd change the display engine to use the combined matrix:
> 
>     render buffer text to desired-glyph-matrix
>     combine desired-glyph-matrix with overlay-matrix into combined-matrix
>     send combined-matrix to screen

If you mean that literally, then the above will disable (almost) all
redisplay optimizations, and will cause Emacs always to display each
window in its entirety.  Redisplay optimizations require that Emacs be
able to _reason_ about parts of the window display being unchanged, by
looking at the related objects and variables -- buffers, overlays,
etc.  You introduce a factor into this equation about which Emacs will
not be able to reason, because its relation to the other objects is
unknown.

E.g., the most frequent redisplay use case is cursor movement with no
other changes.  This case is detected and handled specially, because
it must be fast.  How will that work with your proposal, when cursor
motion will (or could) change some parts in that "second" matrix?

Am I missing something?