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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 26 Jun 2017 10:18:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: alexanderm@web.de, 27427@debbugs.gnu.org
> 
>  > Yes.  We simply overwrite the glyph matrices with the menu contents,
>  > and then force a screen update.
> 
> We would have to do the same for popups.

Doing that behind the back of the display engine is problematic, see
below.

>  > But this cannot work for features that want Emacs to return to the
>  > main loop, because anything that triggers any kind of redisplay will
>  > restore portions of the display from buffer text and mess up the menu.
> 
> And for popups it would just have to overwrite the glyph matrix again.
> Or what am I missing?

If we let Emacs escape into the main loop, we cannot control when
redisplay kicks in and what effect does it have.  For example, some
timer could display a message that could be longer than a single
screen line, so Emacs will resize the echo area and as result
redisplay the windows above the mode line.  Since the text of the
popup comes from a source about which the display engine knows
absolutely nothing, redisplay will do its job assuming that the screen
shows the contents before we overwrote it, and thus will completely
mess up the display.  Even if the code which displayed the popup gets
control right away (which isn't guaranteed in general, since
company-mode wants to be able to run arbitrary Lisp given user
interaction with the popup), the user will see a momentary flash of
messed-up display.

> Yet I doubt that such popups would be desirable on terminal frames.  For
> my taste, they would appear far too obtrusive and distracting.  I think
> any such popup should be treated like a tooltip and get displayed in the
> echo area.

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.