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

[Dmitry Gutov]

On 10/18/17 7:35 PM, Eli Zaretskii wrote:

> 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 other functions with PIXELWISE argument just have it change the 
return value to be pixelwise, that's all. So I'm for consistency here.

With the changed name, it will be the first function to have an argument 
that controls pixelwise-ness, that is named something else :)

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

Sure. Although I'd rather the third value made it return the "inner" 
width, and nil and t meant to measure the same thing (at the cost in 
some backward incompatibility with the pre-release Emacs versions). But, 
again, I'm not saying this issue is critical.

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

All right, that's a good point, thank you. I'll look into this again 
when I revisit the code.

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

Hmm, maybe so. But then we'll have to switch to floats everywhere, for 
this to have a meaningful benefit.

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

Sounds GTM.