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

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

[Sean Perry]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

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. The
suggestions boil down to a few choices

* stop using dynamic format and explicitly set a format like "%7d ".
  Note the trailing space.
* specify a function to return the format which will include the
  trailing space
* edit the source to ensure a space is added when the line number is
  finally rendered.

I dislike all three choices. Choice 1 will usually eat too much room
on the left. That is why dynamic was created in the first place. The
format handler routine option in Choice 2 is inefficient to implement
since the user will need to basically reimplement the dynamic logic and
this is called for every line in the file. If you follow some of the links on
StackOverflow there are several solutions to this and similar problems
that all reproduce the dynamic logic.

I finally chose to implement a variation of option 3 which is attached as a
patch. Basically it lets the user specify a padding value to added when
the line is rendered. The patch is small, easy for a user to implement
and efficient in execution. It certainly seems easier than the solutions
involving defadvice and the dynamic format logic.

For now I have a fork of linum in my .emacs.d/site-lisp. My patch to
linum is attached. Feel free to change the name of the customization
variable or improve the help text.

Sean


[-- Attachment #2: linum.patch --]
[-- Type: application/octet-stream, Size: 1032 bytes --]

--- linum.el	2012-09-12 12:16:20.000000000 -0700
+++ linum.sperry.el	2012-09-12 12:17:58.000000000 -0700
@@ -53,6 +53,12 @@ See also `linum-before-numbering-hook'."
   :group 'linum
   :type 'sexp)
 
+(defcustom linum-margin-padding 0
+  "Padding added to the left margin when displaying the line numbers.
+Should be a positive integer. A value between 1 and 5 is probably sufficient."
+  :group 'linum
+  :type 'integer)
+
 (defface linum
   '((t :inherit (shadow default)))
   "Face for displaying line numbers in the display margin."
@@ -157,7 +163,7 @@ and you have to scroll or press \\[recen
                               (push o linum-overlays))
                             (setq linum-available (delq o linum-available))
                             (throw 'visited t))))))
-        (setq width (max width (length str)))
+        (setq width (max width (+ (length str) linum-margin-padding)))
         (unless visited
           (let ((ov (if (null linum-available)
                         (make-overlay (point) (point))

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

[Stefan Monnier]

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

If it's not a display glitch, can you explain what it is?

> +(defcustom linum-margin-padding 0
> +  "Padding added to the left margin when displaying the line numbers.
> +Should be a positive integer. A value between 1 and 5 is probably sufficient."

While I don't think it's "useful in theory", I do see that it could be
useful in practice to work around problems due to variable-pitch fonts,
for example, where linum.el is not able to correctly compute the actual
width that the text will need.

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


        Stefan

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

[Sean Perry]

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?

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

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

[Alan Third]

Sean Perry <shaleh@speakeasy.net> writes:

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

Hi, is this still an issue for you? I can't reproduce it in Emacs 25.
-- 
Alan Third

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

[shaleh]

[-- Attachment #1: Plaintext Version of Message --]
[-- Type: text/plain, Size: 507 bytes --]



On Thu, 26 May 2016 20:56:05 +0100, Alan Third  wrote:

       Sean Perry  writes:

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

Hi, is this still an issue for you? I can't reproduce it in Emacs 25.
--
Alan Third

I do not know. I am not running 25 yet :-)
 
I will test this on OSX and respond again. I am not seeing it on my
Linux workstations.


[-- Attachment #2.1: HTML Version of Message --]
[-- Type: text/html, Size: 939 bytes --]

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

[Alan Third]

shaleh@speakeasy.net writes:

> On Thu, 26 May 2016 20:56:05 +0100, Alan Third <alan@idiocy.org> wrote:
>
>  Sean Perry <shaleh@speakeasy.net> writes:
>
>  > 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. The
>
>  Hi, is this still an issue for you? I can't reproduce it in Emacs 25.
>  -- 
>  Alan Third
>
> I do not know. I am not running 25 yet :-)
>
>  
>
> I will test this on OSX and respond again. I am not seeing it on my Linux workstations.

It's been over a year since this bug report had any action. I still
can't reproduce it so I think it must have been fixed. We also have
display-line-numbers-mode available in Emacs 26 which appears to provide
the desired padding behaviour out-of-the-box.

If you're still seeing the problem, please let us know.
-- 
Alan Third