[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: Sun, 21 Jun 2015 20:46:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 06/21/2015 07:24 PM, Eli Zaretskii wrote:

Ugh...  Why doesn't ELPA have the latest code?

Because GitHub provides certain niceties as a project (and code) hosting plaform. This has been discussed before. Company is not the only project to host on GitHub and only push releases to ELPA.

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.

That kind of confusion isn't good for a code completion framework.

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. Same for the extra questions in the following email.

Sorry, I'm not following, or maybe I don't understand the underlying
issues.  (I've re-read that bug, but I don't think it's relevant to
what I'm asking here.)  My question is about the newlines that get
inserted into the overlay string.

We can't really use a different rendering approach for every distinct layout of the buffer text: I'll go crazy.

Originally, the overlay (usually) started after the newline, and the popup was rendered using an overlay spanning the next 10 lines.

Now that we've found out that the `display' text property beginning right after that newline can really screw things (make the display value appear twice), the popup overlay begins one character earlier, and includes that character in its display string.

If that sounds like an overlay priority war, it pretty much is; except one can configure overlay priorities, but they can't do that for `invisible' vs `display'.

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.

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

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). Admittedly, it's a recent development; previously, Company inserted a temporary newline, tracked it, and removed it after completion. And caught its share of bugs because of that.

reply via email to

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