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

Previous Next

Full log

View this message in rfc822 format

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: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup
Date: Sat, 24 Jun 2017 02:26:23 +0300

On 6/23/17 12:10 PM, Eli Zaretskii wrote:

> Sorry, I thought that by "related to this" you alluded to the
> zero-column-at-BOL assumption.

I just meant that until now this code coped pretty well with what can be 
found in practice. There are various issues, but none of them were 
zero-column related.

> Not really.  The display engine was always inserting stuff at the
> beginning of a visual line.  Some features that use this include
> line-prefix and wrap-prefix, the left truncation glyphs, and
> overlay-arrow.  It's just that AFAIU company-mode has coded
> workarounds for each one of them, and now there's one more feature to
> deal with.

I don't remember (or see in the code) any workarounds for any of these, 
aside from line-prefix text property. Maybe we're missing certain 
problem situations, of course (examples welcome). Do most of these only 
appear in non-graphical mode?

>> Why not put it outside of the window bounds next to the "actual"
>> margins? That's one option.
> 
> That option requires a thorough redesign of the canvas geometry used
> by the display engine: currently there's no area for it to put glyphs
> except the 3 existing ones -- the two margins and the text area.

In that case, I think we should try harder to make use of the margins.

> As long as only one mode uses the margins, no problems indeed.  Once
> there are two or more, they need to work around one another, and that
> doesn't work very well, sometimes not at all.

Violent agreement, isn't it?

Again, it's a known problem. You're trying to work around it in a way 
that doesn't scale to any potential similar new features, and which 
breaks company-mode popup (and probably some other overlay-wrangling 
code as well, I'm guessing).

I'm saying the users seem willing to wait for a scalable solution, and 
use a margin in the meantime. After all, we have two margins, and two 
fringes as well.

>> But of course, it would be ideal if you could also introduce a facility
>> that would allow sharing of margins (and hopefully also fringes) between
>> different modes.
> 
> Alas, we don't have any consensus for how should this be done.

I can try to outline a possible API. Do we have an existing bug report 
where that discussion would be better placed?

If you have a link to a previous discussion, that would be great as well.

>>> Not sure what you mean by "chromeless" here, but if I understand you
>>> correctly, Martin's work is already on master.
>>
>> I think so, yes.
> 
> I'd urge you to see if company-mode can switch to using these
> facilities, as working against the display engine works only up to a
> point, and doubtless causes many maintenance headaches.

It sounds like a fair amount of work, so it's low on my list. Improving 
ruby-mode and xref seems more important.

>> Yes, but also the lack of ability to disable the line numbering on a
>> line-by-line basis (which could be one solution for this problem).
> 
> If providing such a facility would solve the problem, it should be
> easy to code.  E.g., we could have a display-line-numbers-disable
> property which a Lisp program could put on the first visible character
> of a visual line, and a non-nil value of that property would signal to
> the display engine not to produce the line-number glyphs for that
> visual line.  Would that be okay?

Should be fine, if we find no better choice. As long as that property 
can be set via an overlay.

> (Note that line-number display
> produces glyphs even for lines for which no number should be
> displayed, such as continuation lines and empty screen lines beyond
> EOB, so company-mode would need to decide whether it needs to disable
> those as well.  Which is why I wrote "the first visible character of a
> visual line" above, emphasis on "visual".)

Visual line sounds right.

>> Imagine of the line numbers were displayed using line-prefix (I'm not
>> really suggesting that, but...). Then the popup could pick them up and
>> include in the overlay's `display' property text. The user wouldn't see
>> any difference.
> 
> You can do similar things with line numbers: Lisp code can count lines
> as well as C code, and the fact that the line numbers are being
> displayed is easily detected from Lisp.

I can't get to the actual numbers, though. And isn't counting lines in 
Lisp considered too slow? Or why else would we have this new feature?

> (And you didn't yet consider the possibility of _both_ line numbers
> and line-prefix.  Yes, that should be possible, and I intended that to
> be supported.)

I did, it's in the middle of your quote. ;-)

> Anyway, the mess should be expected in any feature which attempts to
> change the display in significant ways, like company-mode does.
> Experience shows that this only works up to a point.  Which is why The
> Right Way to implement such features is to introduce infrastructure
> (on the C level) which will allow the display engine to do the layout
> job as those features need.  Native display of line numbers is one
> step in that direction, from my POV.  I hope that Martin's work on
> child frames will allow company-mode to go in a similar direction as
> well.

Agreed that it's the right direction (although I wouldn't say no to a 
popup library in the core either ;-). Would it help in non-graphical 
mode, though? Does it support non-maximized frames?

> However, this bug report is about letting the current implementation
> of company-mode live in peace with native display of line numbers.  So
> if you tell me that the above-mentioned property will allow such a
> coexistence, I will code it.

Let's try it, if it's not hard to add. I'll report back as soon as it's 
available.

Previous Next

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