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

[Dmitry Gutov <dgutov@yandex.ru>]

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.