bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width

[Eli Zaretskii]

> Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 18 Oct 2017 03:33:52 +0300
> 
> On 10/17/17 7:33 PM, Eli Zaretskii wrote:
> 
> > They are used for 2 different purposes, which are contradictory to
> > some degree.
> 
> But that's true for all core functions with a PIXELWISE argument, isn't 
> it? Yet, the rest measure the same thing in both cases, AFAIK.

It's not uncommon in Emacs to have optional arguments that modify the
behavior of a function and thus affect their results.  It could be
that this is the first such function whose optional argument happens
to be called PIXELWISE, but if thats the problem, we can easily change
the name, and I will probably do so.

> > The value in column units is primarily meant to be used
> > for setting display-line-numbers-width (see, e.g., how
> > display-line-numbers.el uses that), and also for users, so burdening
> > them with anything that is not directly related to the value of the
> > largest visible line number would be a nuisance.
> 
> Maybe display-line-numbers-width could include the separator columns as 
> well.

I think I will add a 3rd value of the PIXELWISE argument, which will
report the full width, but in units of the frame's canonical character
(such a result will have to be a float, though).  I think this will
satisfy your needs, and the needs of other applications.  Do you
agree?

> > OTOH, the
> > column-unit value is of limited utility for layout calculations,
> > because the columns are of the line-number face, which could be
> > smaller or larger than the default face.
> 
> That changes little for me: overlay-based layout can't do anything with 
> pixels anyway. If all I can do is divine the resulting value by 
> frame-char-width and hope for the best, I might as well use the return 
> value in columns to begin with.

Are we miscommunicating?  The value returned by the function when its
optional argument is nil or omitted is in columns of the line-number
face, not of the frame's default face.  E.g., if someone customizes
line-number to use a font that is twice as large as that used for
'default', the result will be half of what you'd expect.  So dividing
by frame-char-face is exactly the wrong thing.

In a nutshell, when the optional arg is nil, the return value is the
number of digits allocated/used for displaying the numbers, not the
number of columns it takes.  I hope I've succeeded in explaining the
issue now.

> Furthermore, in Company, we already call similar functions (like 
> window-body-height) with PIXELWISE nil.

That function returns its value in units of frame's canonical
character width, so it suits your needs much better.

> I can't help but worry about how an off-by-one error in pixel width 
> (which is not strictly defined) would result in an off-by-one error in 
> column width after division. And again, I'm in no position to use the 
> pixelwise value.

The division should be done with floats, then the accuracy loss due to
off-by-one errors will not be that catastrophic.

> > I agree that this is not ideal, to say the least, but I hope you at
> > least understand the issues now.  If there's a better solution, I'm
> > all ears.
> 
> display-line-numbers-update-width might look worse, I agree. But we 
> could have two functions, right? Both line-number-display-width and 
> display-line-numbers-update-width could delegate to 
> line-number-display-inner-width.
> 
> Just a suggestion.

I think it's better to keep the number of similar functions to a
minimum, otherwise it's hard top remember which does what.  I see no
problem to have a single function serve 2 or 3 different purposes,
controlled by optional arguments.  We do this elsewhere.