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

[martin rudalics]

> Alas, that is not how redisplay works.  For starters, you seem to
> assume that it always traverses all the screen lines of a window (thus
> "on the next buffer line" etc.).  But that is only so when a window
> needs a complete redisplay, and the display engine tries very hard to
> avoid that.  Many times it only redraws some of the lines, sometimes
> just one line.  If that line is not the first line of the popup, how
> will the display engine know that at some previous buffer position
> there is an overlay?

Because an application would include that very line in the 'tty-popup'
overlay BEG...END range and the display engine has to know how to handle
an overlay that spans multiple lines.  Right?

> Moreover, the same low-level display code is invoked by the move_it_*
> functions which simulate display without drawing anything, and those
> are very often invoked to traverse small portions of a buffer,
> typically a small number of lines.  These will be in trouble as well,
> for the same reason.

And still would have to be able to handle multiline overlays as
described above.

> So we need a different solution, one that doesn't break due to
> redisplay optimizations.

Then consider the ‘tty-popup-frames’ list approach: It would have to
remember the start and end glyph matrix positions of the popup frame as
drawn the last time and if these intersect with what has been redrawn in
an optimized way then it would have to (1) restore the old contents of
the popup frame by the real buffer text, if necessary and (2) rewrite
popup frame parts, if necessary.

martin