[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: Wed, 24 Jun 2015 00:15:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

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