[Top][All Lists]

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

bug#27427: 26.0.50; Native line numbers lead to display error in company

From: Dmitry Gutov
Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup
Date: Wed, 21 Jun 2017 05:18:38 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0

On 6/20/17 6:04 PM, Eli Zaretskii wrote:

With (setq line-prefix "..."),

(car (posn-col-row (posn-at-point))) suddenly returns 3 at bol.

I guess you think this result is incorrect, but I don't think I
understand why.  posn-col-row returns the horizontal window-relative
coordinate in units of the frame's canonical column width, so it is
expected that its value at BOL will be non-zero when there's a
line-prefix displayed there.

From where I'm standing, it points to a design flaw in how line-prefix is implemented. Or at least it hints that the native line numbering shouldn't use it, and should use fringe or margin (like linum and nlinum do), or something like them that's considered to be outside of the window by the display engine.

Can you tell how this value is used in company-mode?  I think the key
to my understanding why this change interferes with company-mode is in
that direction.

We've discussed it before, but here's a reminder.

Company draws popup by taking a number of lines that the popup would cover, collecting them into strings, modifying those strings to "draw" the popup on top of them. These operations use the "current row" and "current column" results, respectively.

Then, it (without going into nuance) puts an overlay over the said buffer lines, makes it `invisible', and puts a strings consisting of concatenation of those modified lines on the overlay's `display' property.

When the position at bol is interpreted as "column 3", all lines of the rectangle are rendered starting with the fourth character of each line. Somehow, the result turns out to be uneven, and the first line of the overlay doesn't get affected by line-prefix (so the popup there ends up at the proper horizontal position), but the rest are affected, and they're displaced three columns to the right.

We do support line-prefix when it's assigned via text property.

If you do support the line-prefix property, why are there problems
with line-prefix the variable?  The effect on display is the same,

The way we support the property is impossible to translate to the variable. For each line, we take the value of `line-prefix', prepend it to the line text, and the popup overlay (the one that covers all of the affected lines) gets the `line-prefix' property set to "".

reply via email to

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