Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What causes this graphical error in emacs with linum-mode on OS X?

Tags:

emacs

I get this graphical error with linum-mode in my Emacs. I tried upgrading from 23 to 24 (via git) and I've tried both with various supplied binaries online and with my home-compiled version. What I'm really interested in is where to start diagnosing the problem.

"Tearing" of numbers in linum-mode

The problem goes away if I scroll the torn line numbers off screen and back in.

like image 940
Sarah Avatar asked Feb 07 '11 10:02

Sarah


3 Answers

to make a separation between the line numbers and the buffer text, the follow change will be better:

In version 0.9x of linum, change line 150 from

(concat "%" (number-to-string w) "d")))))

to

(concat "%" (number-to-string w) "d ")))))

This make the separation have the same background color with line numbers'.

like image 175
jessex Avatar answered Sep 28 '22 09:09

jessex


I have experienced the same problem and spent quite some time trying to resolve it. The graphical error is a result of a clash between linum-mode and how the fringe is rendered. Unfortunately, I was unable to resolve the problem in linum.el, and the fringe display code is part of the C-source.

It can still be done! The easiest way to fix it is to just turn off the fringe.

M-x fringe-mode RET none RET

To make the fringe permanently stay off, I recommend customizing the settings with M-x customize-group RET fringe because some compiled versions of Emacs for Mac OS X have their own fringe settings that can override parts of your .emacs file.

I don't really need those line wrap indicators, so not having a fringe doesn't bother me. However, I did miss a slight separation between the line numbers and the buffer text. I followed the advice of a post on the Emacs Wiki to get that spacing back. In version 0.9x of linum, change line 160 from

(setq width (max width (length str)))

to

(setq width (max width (+ (length str) 1)))

The inspiration for this change is here: http://www.emacswiki.org/emacs/LineNumbers

There are arguments at the source link to set the linum-format variable instead of modifying linum.el. While I understand where they are coming from, most color-themes these days would color the extra space and not provide what I am looking for (a separation of about a space that is the background color). If you do edit linum.el, make sure to run

M-x emacs-lisp-byte-compile-and-load

to make the changes persistent. You can see the result of this by looking at the space before the cursor in the picture found here: http://i.stack.imgur.com/TxyMr.png (I don't have enough reputation to embed images).

No more graphical artifacts!

like image 11
Pat O'Keefe Avatar answered Nov 05 '22 00:11

Pat O'Keefe


I had the same problem and I figured out a solution and while it's not the prettiest, due to an extra space to the left of the line number, it's much more elegant than changing the linum.el. Here is the pertinent part of my ~/.emacs:

;; Linum mode                                                                                                                                                                                                                           
(global-linum-mode t)                                                                                                                                                                                                                   
;; Offset the number by two spaces to work around some weird fringe glitch                                                                                                                                                                     
(setq linum-format "  %d ")

This removes the fringe overlay issue and does not have any other impact other than offsetting the line number.

like image 8
Jeremy Whitlock Avatar answered Nov 05 '22 00:11

Jeremy Whitlock