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

[Eli Zaretskii]

> Cc: alexanderm@web.de, 27427@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 24 Jun 2017 02:26:23 +0300
> 
> > 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?

Not necessarily.  E.g., disabling the fringes will cause Emacs to
display left-truncation glyphs on GUI frames as well.

I guess you were just lucky, because in all of the other cases the
additional horizontal shift was somehow either accounted for or (in
the case of overlay-arrow) non-existent.  But the principle still
stands: the display engine is allowed to insert glyphs it invents out
of thin air at the edges of the text area, and Emacs always made use
of this.

> Again, [display in margins is] 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).

It will only break modes that assume too much about layout.  And given
the popularity of the line numbers, there's no other practical way
except adapt those add-on packages, starting from company-mode.

> I'm saying the users seem willing to wait for a scalable solution, and 
> use a margin in the meantime.

I think you have it backwards: the margin-based solutions were tried
and were found not to be scalable.

> >> 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?

Bug#24193.

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

Here's one (I think there were more):

  http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01171.html

FWIW, I don't recommend going in that direction, as I believe we will
again bump into the same basic disagreements due to conflicting goals.
That's why I decided to stay away of the margins in the first place.

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

OK, I will add that.

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

count-lines should give them to you, no?

> And isn't counting lines in Lisp considered too slow?

When done as part of routine redisplay, off the post-command-hook,
yes.  But company-mode is not used during routine redisplay, as in
during scrolling through the window, right?

> Or why else would we have this new feature?

Producing line numbers as part of redisplay was indeed intended to
make it faster, since all the line-numbering add-ons basically induce
an immediate additional redisplay cycle, because they change
overlays.  But that was only one of my goals, the other was to do in
the infrastructure something that can be done well only there.

> > 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?

AFAIU, it supports any kind of frame.

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

Thanks.