bug#12428: 23.4; Add padding for rendering of the line numbers by linum-mode

[Sean Perry <shaleh@speakeasy.net>]

On Oct 26, 2012, at 9:47 AM, Stefan Monnier wrote:

>> I was experiencing the issue discussed here at StackOverflow
>> http://stackoverflow.com/questions/4920210/what-causes-this-graphical-error-in-emacs-with-linum-mode-on-os-x.
> 
> I'm not sure I understand what is the problem there.  Is it really
> a display glitch where the fringe is displayed on top of the margin?
> If so, that's just a bug that needs fixing.  I.e. please provide
> a recipe (I haven't bumped into such a display glitch in my tests
> of linum.el).
> 

That is exactly the issue. When I turn the fringe off the text of the buffer is now right next to the line numbering so I wanted some padding. I thought other people might too without changing their fringe settings. I agree the bug needs fixing. I just do not know whose bug it is.

For me this is very easy to reproduce.

Load a no config emacs. Open some code that is over 100 lines long -- you need 3 digits of numbering to really see it although it is present with less. Start linum-mode. The number 1-9 are ok but ever so slightly chopped. The 10-99 show clear chopping.

Now set the following.
(custom-set-variables
 '(fringe-mode (quote (0)) nil (fringe))
)

Now the numbers are fine but the code display is ugly since there is no padding.

 I am using the emacs for mac osx build of 23.2. "This is GNU Emacs 23.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.29) of 2010-05-08 on black.local" as well as 23.4.1. I just downloaded the build of 24.2 and it is still there. I only have 23.1 on my local Linux installs. It does not reproduce there. It may be a font related issue on OS X. The default for Emacs on OSX is Monaco which is indeed monospace. If I switch the font by putting just this in ~/.emacs
(set-face-attribute 'default nil
                 :family "Inconsolata" :height 145 :weight 'normal)
I can clearly see the line being drawn through the linum numbers. Set the height to 90 and the back of the numbers are being obscured instead. The screen capture in the link to StackOverflow shows this nicely.

> 
>> -        (setq width (max width (length str)))
>> +        (setq width (max width (+ (length str) linum-margin-padding)))
> 
> Why not add linum-margin-padding only at the end, in the call to
> set-window-margins?
> 

Because it made the call to set-window-margins noisier than it needed to be. We still want to use (max) since there is no need to add the padding unless the desired width requires it.
Do I misunderstand the code?