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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: alexanderm@web.de, 27427@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 22 Jun 2017 01:41:15 +0300
> 
> On 6/21/17 9:15 PM, Eli Zaretskii wrote:
> > Or do you just assume the column there is
> > zero?
> 
> Yep! And there are zero outstanding bug reports related to this.

Well, except this one ;-)

> > What I had in mind is to come up with a solution that will work the
> > same with line-prefix specified in any way we support.  Then you won't
> > need to put the line-prefix property on the company overlay.
> 
> I'm saying it's not easy, and I'm not brimming with ideas.

Is it not easy because the assumption about column-zero is hard-coded
in many places?  Or for some other reason?

> Can't we put native line numbering outside of the window bounds? Like 
> linum and nlinum do.

Keeping the numbers out of the margins was my explicit design goal,
because some packages want the margins, and we don't have a good
solution for "sharing" margins.  So from my POV putting the numbers in
the margins would be a step backward.  It will probably also create
major havoc for the few packages that do display in the margins,
because Emacs facilities for layout of text and other stuff there are
exceedingly limited.

> IIUC we've settled on using chromeless frames for the popup. It seems 
> Martin is cooking something in this direction (almost ready?), but I 
> haven't tried using them. And that would take some work.

Not sure what you mean by "chromeless" here, but if I understand you
correctly, Martin's work is already on master.

> 1. The first visual line containing the popup has the line number at its 
> beginning. And as such, the popup line is shifted to the right.

That's the "BOL at non-zero column" issue, right?

> 2. The rest don't have the line numbers before them, so they are 
> positioned correctly. This may or may not be considered a problem 
> (there's probably nothing we can do about the lack of numbers), but the 
> inconsistency between the different popup lines seems like it would 
> require some special handling in the code.

The lack of numbers is a "feature", I think: only "physical" lines in
buffer text are counted, newlines in overlay and display strings do
not count.

Can you artificially offset the beginning of the overlay to account
for the line numbers, and see if that alone solves the problem of the
first lines, and doesn't cause problems in the subsequent lines?

Thanks.