bug#26552: [patch] nlinum margin width calculation (emacs <25)

[Christophe Rhodes <csr21@cantab.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Christophe Rhodes <csr21@cantab.net>
>> Date: Mon, 17 Apr 2017 22:26:56 +0100
>> 
>> I think the calculation that nlinum-mode does to guess the margin size
>> in the absence of font width information (in emacs versions less than
>> 25) uses the wrong bit of font information: the pixel size, rather than
>> the font height.  Trivial patch below, which fixes the problem for me.
>
> Isn't it a mere coincidence that this fixes your problem?

I don't think so.

The calculation is trying to compute how many characters should be
reserved in the margin, which will on a graphical display (I presume)
reserve space in units of frame-char-width.

In the case that the face for linum/nlinum is the same as the face for
everything else (in particular, the face used for frame-char-height), we
want to reserve the number of character cells that is equal to the
length of the strings we will need to format, nlinum--width.  But
frame-char-height is the height (in pixels) of the lines in the frame,
not the height of the characters in the font -- it includes leading.
So, when computing the number of characters to reserve, the inclusion of
leading in the denominator but not the numerator eventually leads to an
underestimate in the number of characters to reserve.

> How can height be a better approximation for width than size?

It's not, but the ratio of one height (the font height) to another
height (frame-char-height) is a better approximation to the scaling
ratio between widths, which is what really matters, than the ratio of
the font pixel size to the frame-char-height (which are two quantities
without a direct relationship).

> What are the actual numbers in your case?

My font is Source Code Pro 10, which has pixel size 13 and height 17;
frame-char-height is 17.  So once nlinum--width is 5, the current
computation underestimates the space needed; with my patch, the
calculation is correct for all values of nlinum--width.  I haven't
tested with different sizes for the linum face and the normal face; I
expect my patched calculation to approximate better than the existing
one in essentially all cases.

Best wishes,

Christophe