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

[Stefan Monnier]

retitle 12428 Display glitch in margin with linum-mode on macosx
reassign 12428 emacs,ns
thanks

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

This does not sound like a display glitch, right?

Instead the issue is that you want a visible separation between the
buffer text and the margin's content, even when the fringe is off (or
when fringes-outside-margins, I guess).

So, indeed, that's a case where adding some padding to linum's format
can make the problem somewhat less annoying.

> I thought other people might too without changing their
> fringe settings.  I agree the bug needs fixing.

When you say "the bug" you mean the issue above?  If so, please file
a separate bug report (well, it'd be a feature request, but M-x
report-emacs-bug is The Right Thing for that as well) for that.

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

I do not see this at all (here on Debian GNU/Linux).  I did "emacs -Q
src/regex.c" and then M-x linum-mode and none of the line numbers are
chopped (neither at the beginning nor at the end of the buffer).

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

Yes, I see that the two are too close to each other.  That's the above
discussed issue (one could argue it's a pilot error: you asked for "no
fringe" and you get what you asked for).

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

This sounds like a display bug, probably specific to the macosx code.
Someone else will have to look into this, since I know nothing about
this code.

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

I don't understand: when would the padding not be necessary?
Or is it because you want this padding to work around the macosx display
bug, rather than work around the other issue discussed above?  If so,
I'd rather not do that, and focus on fixing the display bug instead
(unless fixing this bug is difficult, but I see no reason for that).


        Stefan