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

[Eli Zaretskii]

> Date: Tue, 27 Jun 2017 17:27:45 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org
> 
> 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’.

Then I don't understand what you are suggesting.

> 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).

Menu code proves that we can do that, but it also proves that we must
prevent Emacs from redisplaying anything for the entire time the menu
is active.  We do that in the menu case by various tricks, but those
are only possible because as long as the menu is active, Emacs is
conceptually stuck in a long input operation, and thus preventing
redisplay raises only minor issues, like display-time stops updating.
But company-mode wants to be able to reflect the current selection
immediately, even before the popup pops down (AFAIU), and in general
wants to be able to run arbitrary Lisp during the popup activation,
and that just cannot live with the tricks used by TTY menus, because
sooner or later redisplay will happen, and will mess up the screen, as
the glyph matrix created from buffer text will overwrite the stuff we
put there.

I hope I explained myself this time.

> So such a region can cover mode and header lines, span multiple
> (Emacs) windows---virtually everything that can be found within the
> frame edges.

It can -- until the first time redisplay kicks in.

> 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.

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.