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

[Eli Zaretskii]

> Cc: 20847@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 21 Jun 2015 20:46:59 +0300
> 
> >> 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.

No, I expect the cursor to be drawn on the fringe, like the user
expects.  (Or maybe I misunderstand what you meant by "earlier".)  You
should give the 'cursor' property an integer value, so that it
"covers" the buffer position of the newline.

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

Unlikely.  I've clearly identified the code that moves point, as part
of redisplay, and traced it through the part that decides the cursor
cannot be set on the line with "hel".

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

There are only 2 situations, from your POV: either a line goes all the
way to the window edge, or it doesn't.  The former can happen either
if there's a newline that ends a line, or if word-wrap is in effect.

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

Yes, there could be such artifacts, but IMO losing some of the text is
worse.  And the problems you describe will be only on the lines
actually used for the popup; the rest of the lines, which just copy
buffer text into an overlay string, will look exactly like they did
before, including the continuation markers.

Anyway, if you think what you have now is justified by the complexity
of the alternatives, fine with me.

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

I had no problems with that newline.