GNU bug report logs - #27427
26.0.50; Native line numbers lead to display error in company-mode popup

Previous Next

Full log

Message #23 received at 27427 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alexanderm <at> web.de, 27427 <at> debbugs.gnu.org
Subject: Re: 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

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.