bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup

[martin rudalics]

> But the display engine is not involved in the TTY menus, at least not
> in the usual sense.  Please take a look at the second half of
> display_menu_bar, and you will see what I mean.

Isn't display_menu_bar the code for displaying a non-X GUI menu?  I
suppose you allude to the "while (!leave)" part of tty_menu_activate.
Please correct me if I'm wrong.  I don't understand why this should be
relevant for popup frames, probably because I'm too silly.

So let me try again how I think a popup frame could be emulated on a
TTY.  Currently, on a TTY a popup frame is nothing else but a normal
frame because all special frame parameters are inhibited.  Hence, it
will have the same size and position as the frame above which it is
supposed to pop up, which doesn't make any sense.

To specify the position and contents of a popup frame on a TTY I see two
ways: Either in the buffer text via a normal Emacs overlay with a say
'tty-popup' property or via a separate list say ‘tty-popup-frames’.  The
following sketch is based on the former.

An overlay with a 'tty-popup' property would specify a buffer position
and a newline separated text.  The buffer position would implicitly
provide the upper left corner of the popup frame, the text its size.

The display engine would notice the overlay like any other overlay.
However, the 'tty-popup' property would cause it to (1) remember the
current column of the iterator and (2) draw the first line of the
overlay right where the iterator is at this moment, possibly clipping
this line of the overlay text at the frame edge and skipping as many
characters of underlying buffer text as there are on this overlay text
line.

On the next buffer text line the display engine would start to draw the
second line of the overlay text at the column remembered in (1),
clipping and skipping as on the first line.  It would continue to
process the overlay until either its text has been used up or the bottom
of the window or the frame's root window has been reached.

Any redisplay would now redraw the popup frame in the same way, possibly
at a different position or with different size.  The overlay would
probably need a 'window' property to allow showing the same buffer
position in several windows and some convention would be needed for how
to draw overlapping popup frames.  The overlay would be removed from its
buffer by the same function that makes the GUI popup frame invisible or
kills it.  Removing the overlay would cause a redraw just like removing
a GUI popup frame would cause an expose event and a subsequent redraw.

I don't think that the extra check for the column stored in (1) would be
overly expensive.  If a separate ‘tty-popup-frames’ list were used (each
entry containing a buffer position and a newline separated text), then
an approach where the desired glyph matrix is overwritten as with TTY
menus would be used.  This would remove the need for (1) at the expense
of calculating the desired position of the popup in the glyph matrix
from the buffer position and the need to overwrite the relevant portions
of the desired glyph matrix.

martin