bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/21/2015 07:24 PM, Eli Zaretskii wrote:

> Ugh...  Why doesn't ELPA have the latest code?

Because GitHub provides certain niceties as a project (and code) hosting 
plaform. This has been discussed before. Company is not the only project 
to host on GitHub and only push releases to ELPA.

>> Which character should I put this property on in this situation, then?
>
> The one before, I think.  Like I explained later:

I see. But that's going to look confusing: if the cursor appears 
earlier, the users are going to assume (at least from time to time) that 
they haven't typed the last character yet.

That kind of confusion isn't good for a code completion framework.

> I didn't investigate why this happens.  Is it important?  Suppose I
> "fixed" it by having the cursor on the same place in the second
> paragraph where it ends up later -- will this be better in some sense?
> If so, I will look into it.  (It's probably some redisplay
> optimization that needs to be disabled in that case.)

Not really important. I just thought it might be a detail that would 
lead you to a different explanation for this bug. Same for the extra 
questions in the following email.

> Sorry, I'm not following, or maybe I don't understand the underlying
> issues.  (I've re-read that bug, but I don't think it's relevant to
> what I'm asking here.)  My question is about the newlines that get
> inserted into the overlay string.

We can't really use a different rendering approach for every distinct 
layout of the buffer text: I'll go crazy.

Originally, the overlay (usually) started after the newline, and the 
popup was rendered using an overlay spanning the next 10 lines.

Now that we've found out that the `display' text property beginning 
right after that newline can really screw things (make the display value 
appear twice), the popup overlay begins one character earlier, and 
includes that character in its display string.

If that sounds like an overlay priority war, it pretty much is; except 
one can configure overlay priorities, but they can't do that for 
`invisible' vs `display'.

> The original buffer text is one
> long line, without any newlines, which occupies several screen lines.
> Why cannot the overlay string be simply a copy of that text, a single
> long string without any newlines?  The display engine will display
> them with the continuation indicators on the fringes, exactly like it
> does for buffer text, and the user will not "lose" those characters at
> the end of each line.

Can't say I've considered this before, this sounds more complex that 
what we have now, and depends on lines being wrapped in a certain way.

First, what if visual-line-mode is on? Then we'll have to track the 
presence of it and similar modes.

Second, the continuation characters will look out of place (and we'll 
have to have them for the next 10 lines, right?). Because normally you 
don't see them, but if the overlay rendering switches to wrapped lines 
instead of newlines, they will always be present (or rather blink in and 
out of existence as the popup is displayed or hidden).

>> It also simplifies some logic in the code, because sometimes we have to
>> do this anyway (when the popup is displayed below the last line, and it
>> has no trailing newline).
>
> You have "to do" what sometimes?

Start the popup overlay at the end of the preceding line, and include a 
newline in its display string (because there's no newline in the 
buffer). Admittedly, it's a recent development; previously, Company 
inserted a temporary newline, tracked it, and removed it after 
completion. And caught its share of bugs because of that.