Re: mouse-drag-and-drop-region

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Fri, 17 Nov 2017 10:58:57 -0500
> 
> > Because TTY menus are implemented by overwriting parts of the glyph
> > matrix with text that comes "out of nowhere", as far as the normal
> > redisplay is concerned.
> 
> If we really wanted, we could implement some kind of tooltips in
> a similar way, tho:
> 
> - overwrite parts of the glyph matrix
> - register some "pre-redisplay hook"
> - return to the normal command loop
> 
> the "pre-redisplay hook" would then remove the tooltip-overwrite from the
> glyph matrix before the redisplay bumps into it.  Then if we want the
> tooltip to last longer than "until the next redisplay" (which sounds
> rather likely), we'd need some way to re-add the tooltip after the
> redisplay is done.
> 
> Sounds pretty ugly/messy, obviously.

Not only that, it probably won't work without much more ugliness to
support it.

> A more general solution could be to add two more glyph matrices (one for
> overlay thingies like menus and tooltips, and another that combines the
> "normal" glyph matrix with the one for overlay thingies (and it's this
> one which is then sent to be displayed)).

I don't see how this solves the problem, because the display engine
will still know nothing about that "second" matrix.

The only way to make TTY menus a first-class display citizen is to
come up with some object which the display engine would routinely
consult in deciding what to display in a window.  Right now, it
consults the text of the buffer pointed to by the window, and any Lisp
strings related to the buffer.  We need something else to add to this
soup, and the problem with that something is that it spans several
lines, but only part of each line.  Maybe it should be modeled on the
mouse-highlight, with the assumption of a rectangular region added...