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

[Dmitry Gutov <dgutov@yandex.ru>]

On 6/29/17 7:20 PM, Eli Zaretskii wrote:

>> Different tradeoffs, some different problems, and a lot of common ones
>> (like text scaling, images, character widths, etc).
> 
> But all of these are not relevant to TTY frames, right?

The `display' issue in `M-x report-emacs-bug' should be just as 
relevant. And similar stuff.

Character widths might be relevant as well in some terminals, but that's 
hardly something we could fix in Emacs.

> Martin is trying very hard to come up with a method to overcome the
> fact that Emacs cannot display "rectangular" overlay strings.
> Breaking the string into several one-line strings and putting their
> overlays at the appropriate buffer positions would solve this problem.

Like I said, we have another completion package that does this (but the 
authors refuse to assign copyright).

How will that help with the arithmetics? How is it better than the 
one-overlay approach for the current situation?

>> One-line-per-overlay approach will always work worse in display-heavy
>> buffers, for instance. Like the 'M-x report-emacs-bug' one.
> 
> Why would it work worse in that case?

Imagine that point is above the "If Emacs crashed..." display overlay. 
There is no physical line below it where we can put an overlay with the 
first popup line.

I suppose we could replace (propertize "\n" 'display txt) string that is 
there with a fully made up overlay string, but a) it's less trivial than 
you probably imagined initially, b) the buffer text below it is going to 
jump up and down as the popup is shown and hidden.

With the one-overlay approach, we ignore that `display' property (so 
there's empty space there when the popup is displayed), but preserve the 
height in rows, so the other buffer text is not jumping.