bug#18195: 24.3.92; window-screen-lines is not accurate

[Dmitry Gutov]

On 08/06/2014 10:36 PM, Eli Zaretskii wrote:

> > Multiple overlays aren't much easier to work with: you can't position
> > them in the middle of a piece of text that's on `display' property,
>
> But you could copy the display string into the overlay.

I don't see how this could work with overlays that don't spread over 
multiple visual lines if the aforementioned text on `display' property 
is multiline.

Going back to one-overlay approach, this could work. But then, oh joy, 
instead of "go down 10 lines, collect them and add required pieces at 
between columns 5 and 20", I'll have to see if there's maybe a display 
property on line 3 that spans 15 lines, stop after it, include the 
display property in the text-to-be-replaced. Or, if the text with the 
`display' property starts before the supposed beginning of the overlay, 
I'll have to measure the place where to start replacing the lines 
from... somewhere. If there are multiple pieces of text with `display', 
all the merrier.

All of the above really sounds like a job for a display engine.

> > can't position them after the end of the buffer
>
> Yes, you can: you can include newlines in the overlay string.

Guess so. If another package tries the same with its own overlays, it'll 
be a mess, but here I'm going over into fantasy territory.

> > or overlapping the `line-prefix' value.
>
> Why do you need that?  No buffer text will ever appear in the prefix,
> so your drop-down list doesn't need to invade the prefix area, because
> it is aligned with some buffer text.

The prefixes can be different between lines. They also can be of 
different lengths. `org-indent-mode' is fairly popular, and it indents 
headings of different levels and their contents using `line-prefix'. 
This way, if the completion is initiated on the first column before the 
first header, the popup has to cover line-prefixes below. See 
https://github.com/company-mode/company-mode/issues/24.