[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: Sat, 24 Jun 2017 02:26:23 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0

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

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.

reply via email to

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