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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 20847@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 23 Jun 2015 21:44:58 +0300
> 
> On 06/23/2015 07:39 PM, Eli Zaretskii wrote:
> 
> > Would it be possible in this specific case to start the overlay from
> > the next line, i.e. leave the newline alone?  I think if you do that,
> > things ought to work without any changes.
> 
> I suppose.
> 
> > Since the "tooltip" pops up
> > below this line, it seems to me that the newline which begins the
> > overlay now is not needed, is it?
> 
> "now"?

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

> >> The current example shows that it's better to display the cursor on the
> >> margin, rather than after the overlay. What are the examples where this
> >> is not true?
> >
> > All the others ;-)
> 
> A concrete example would help.

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

> 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"?

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

> (if wouldn't be displayed in the middle of the overlay string, right?).

Never (unless there's a character with 'cursor' property).

> > No, I think what makes this case special is the fact that (the visible
> > part of) the overlay begins on the line below the one where the user
> > types.  So from the user POV, the current line is still occupied only
> > by buffer text, and so users will expect the cursor to be displayed as
> > if there were no overlay at all.
> 
> 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.

> That seems consistent with the logic of expecting the cursor "to be
> displayed as if...".

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

> > By contrast, the "usual" case with overlays that span multiple lines
> > is that the situation with positioning the cursor arises when some of
> > the overlay string is visible on the current line, and then the user
> > expectation is to see the cursor after the string.  That's what the
> > code which handles this situation tries to make happen.
> 
> 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.

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

> >> Even if cursor would look weird in some case, at least point is not
> >> forcibly moved to a different position.
> >
> > We are in agreement regarding the best place of showing the cursor in
> > this case.  The only problem is how to do that.
> 
> Removing that exception might do the trick.

It will bring other problems.

> But then, maybe I don't really understand what it does.

I can tell you which parts of code to read, if you want.