[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20847: [display engine] 25.0.50; company-mode popup makes point jump

From: Dmitry Gutov
Subject: bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location
Date: Tue, 23 Jun 2015 21:44:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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?


If the line after the current has a `display' property, it could still lead to the problem like bug#18285. However, `M-x report-emacs-bug' buffer (which was the main example for that bug) doesn't have particularly long lines, so we could hope the workaround won't be triggered there. But anyway, wrong rendering is still better than moving point to a different place.

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

If it starts earlier, then the cursor might be displayed before or after (if wouldn't be displayed in the middle of the overlay string, right?).

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 seems consistent with the logic of expecting the cursor "to be displayed 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. If it ends later, why would we even try to display the cursor at that newline in the first place?

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. But then, maybe I don't really understand what it does.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]