Re: mouse-drag-and-drop-region

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 18 Nov 2017 09:36:40 -0500
> 
> > 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.
> 
> The above is the *model*.  I'd describe the current model as:
> 
>     render buffer text to glyph-matrix
>     send glyph-matrix to screen

This model is incomplete.  Emacs first tries to reuse (parts of) the
current matrix, if that's possible given the information about what
has changed since the last redisplay cycle.  It only generates a new
("desired") glyph matrix if the attempt to reuse the current one
failed.

In addition, AFAIR there are situations when only small portions of
the desired matrix are generated.  When doing this, Emacs must be able
to decide which parts don't need to be regenerated.

> both models are amenable to various optimizations.  Most of the
> optimizations applicable to the current model should be applicable to
> the other as well.

If you are thinking about reviewing the existing optimizations and
changing them to account for the new model, including adding some new
optimization methods, then I'm sure it's possible.  But it's a large
job, and I cannot promise that the result will be acceptable,
performance-wise, unless very deep changes are done in the control and
logic flow of the current code.

IOW, I think the way redisplay is implemented simply isn't ready for
such changes.  The current implementation of the TTY menus was
proposed by Gerd Möllmann, the author of the current display engine;
if something like what you suggest were feasible, he'd most probably
mention it when this was discussed.  He didn't.  Of course, it's
possible that he simply didn't think about such an alternative, but I
personally find that unlikely.