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

[martin rudalics <rudalics@gmx.at>]

 > I think we are miscommunicating.  I was describing what would happen
 > if we try to use the same method as used for TTY menus.  There are no
 > overlays there, the glyphs are concocted out of thin air by C code and
 > put into the glyph matrices, overwriting what the display engine
 > thinks should be there.
 >
 > By contrast, you are talking about using an overlay,

Sorry for being unclear.  I did mean overlaying text just as the menu
bar code does and did not mean overlays as produced by ‘make-overlay’.

 > which is what
 > company-mode is using already, and which is the source of the trouble
 > Dmitry would like to avoid.  The basic problem here is that the
 > company-mode popup is multiline, and Emacs cannot display rectangular
 > regions, only lines.

But here we talk about the terminal where Emacs can display rectangular
regions because all elements displayed have the same size (the menu bar
code proves it).  So such a region can cover mode and header lines, span
multiple (Emacs) windows---virtually everything that can be found within
the frame edges.

 > So company-mode inserts newlines into the
 > overlay string,

... which is evil because it has to calculate the beginning of the
second overlay (in the sense of being made by ‘make-overlay’) string
which is hardly reliable with proportional fonts, text properties and
all sorts of display artefacts including overlays strings produced by
someone else.

 > and the result is that the popup covers parts of the
 > display which company-mode doesn't want to conceal.  So it needs to
 > copy those parts to the overlay string, to make the impression they
 > weren't covered by the overlay.  It also needs to make all kinds of
 > layout calculations and decisions.  All that in order to make an
 > impression of displaying a rectangular region at certain screen
 > coordinates, something that we ideally should have provided in the
 > display engine.

And I still think we can do that for terminals without any problems
using the same approach you used for menus.  All we need is the buffer
position (whose character represents the preferred upper left corner of
the virtual rectangle) and the text to be shown (with newlines).  Any
clipping or repositioning is up to the display engine as for menus.  And
the lifetime of the rectangular region on screen is that of the popup
frame on a GUI.

 >>   > I don't see how the echo area can fit the job, since the space there
 >>   > is very small and there's no way to let the user select an alternative
 >>   > using menu-like interaction.
 >>
 >> The echo area can be resized and can emulate any menu-like interaction.
 >
 > Yes, but not conveniently.  And if we are going to emulate, why use
 > the echo area at all? why not pop up a buffer, like Help mode does?

Sure.  The echo area is used by tooltip mode and simple questions on
terminals, that's why I mentioned it at all.

martin