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

[Dmitry Gutov]

On 06/23/2015 10:07 PM, Eli Zaretskii wrote:

> "Now" as in "what Company does now".

It very much uses that newline "now". The most recent major change, 
IIRC, was related to working around the previously mentioned 
invisible<->display bug.

> emacs -Q
> M-: (overlay-put (make-overlay 65 66) 'before-string "how\ndo\nyou\ndo?") RET

But there's nothing special about newlines here. The display engine 
probably never "tried" to display the cursor at any of those that are 
inside the display string.

> > The fact that you'd *try to* display the cursor at the newline
> > belonging to an overlay display string indicates that the overlay
> > must start at that position, doesn't it? Or end.
>
> Sorry, I don't follow: what do you mean by "you'd try"?

Consider for displaying the cursor at?

Allow me to quote yourself: "In a nutshell, when a screen line ends in a 
newline that comes from an overlay string, we don't want to display the 
cursor on that line."

For that heuristic to apply, I'd say first you have to "try" to display 
it at that position.

> > If it starts earlier, then the cursor might be displayed before or after
>
> We always display it after, when point is at buffer position that has
> an overlay string property.

So maybe I misunderstood, and there's no heuristic about newline at the 
end of visual line coming from an overlay. And that other circumstances 
conspire to make it seem that way, namely:

- Cursor is always displayed after an overlay when it's "inside" it.
- We somehow always consider point to be "inside" overlay when it's at 
the window edge, and an overlay begins there too.

Maybe the latter could still be changed.

> > (if wouldn't be displayed in the middle of the overlay string, right?).
>
> Never (unless there's a character with 'cursor' property).

Yes, we're not considering this case, for now.

> > If I had to pick, I'd probably always display the cursor before such
> > overlays, not after.
>
> That goes against what Emacs did since we began supporting overlay
> strings.  Among other problems, it makes strange effects when
> inserting characters: they appear not where the cursor is.

Inserting characters with overlays applied already? If you're talking 
about one existing overlay, maybe the behavior should depend on the 
stickiness of the overlay's bounds.

> Again, this case is IMO singular, in that none of the overlay string
> characters are visible on that line.  Thus "as if...".

Maybe it is singular.

> > If the overlay display string ends at that newline, and point is at the
> > end of the overlay, then the display engine exception under the
> > discussion will be a no-op.
>
> What exception?  Sorry, I lost track: we are discussing many different
> things simultaneously.

Again, refer to the quote above. And I probably have misunderstood.

> > If it ends later, why would we even try to display the cursor at
> > that newline in the first place?
>
> Because its corresponding buffer position matches point.  That's how
> cursor positioning works in Emacs: it always starts by looking for the
> glyph on the screen that corresponds to the buffer position where
> point is.  If such a glyph is not found, for one of the many reasons
> (invisible text, overlay or display string, hscroll, you name it),
> then the fun begins: we try very hard to find some alternative
> position that fits.

Then the overlay must begin at the edge of the window, and all the cases 
where your quote (above) applies look like this case.

> > But then, maybe I don't really understand what it does.
>
> I can tell you which parts of code to read, if you want.

If you think that's wise.