When using linum-mode in emacs and when increase font by M-x text-scale-increase, there is the one thing that bothers me. Font for line numbers have same size as reading and don't fit into left-margin on left side of buffer!
1
Normal font-size, OK
2
Increased font-size, no longer readable FUUUUU
What I'd really like to have:
When increase/decrease font I want one of these to work
then increase/decrease width of left-margin (resp. left-fringe) accordingly
then don't change font for left-margin but increase/decrease spacing between line numbers
Does anybody have some suggestions?
Thanks, guys
Have a look at these two links:
my question on the same issue
my workaround for this issue
It works quite well enough for my needs.
Examples:
1
The easiest, most straightforward solution I've seen is to set the line numbers to a fixed height. This can be accomplished easily, in accordance with user78810's answer: https://unix.stackexchange.com/questions/29786/font-size-issues-with-emacs-in-linum-mode/146781#146781
To wit, add the following line in your emacs config (or to your dotspacemacs/user-config function, if you're using spacemacs):
(eval-after-load "linum"
'(set-face-attribute 'linum nil :height 100))
M-x customize-face [RETURN] linum-mode
I think I can fix that problem with the following code:
(require 'linum)
(defun linum-update-window-scale-fix (win)
"fix linum for scaled text"
(set-window-margins win
(ceiling (* (if (boundp 'text-scale-mode-step)
(expt text-scale-mode-step
text-scale-mode-amount) 1)
(if (car (window-margins))
(car (window-margins)) 1)
))))
(advice-add #'linum-update-window :after #'linum-update-window-scale-fix)
It seems to work, at least with 24.5.
I would comment on the solution based on customize-face if I could. It works well for me. The actual face is linum rather than linum-mode, at least in my emacs-24.3.1. In the customization buffer, I clicked on "Show all attributes" and then set the face height to 100 tenths of a point. If a fixed-size face for the line numbers is acceptable to you (as it is to me) the solution based on customize-face is straightforward.
You can disable linum-mode and use display-line-numbers-mode instead which is part of Emacs since version 26 and scales well when increasing font size.
E.g. your config can look like:
;; (global-linum-mode 1)
(global-display-line-numbers-mode)
Related
I am trying to set the line height of text in an Emacs buffer so there is space above and below the letters. From the documentation, I infer that the line-height text property may help me to accomplish this.
There is also a line-spacing variable which I can set like (setq-default line-spacing 0.25). This kind of works, except it does not produce space before text, only after it. I don’t like the way this looks when using modes like show-paren-mode, since it “dips” down:
Undesired current behavior (“hanging”)
Desired behavior mockup (vertically-centered)
I'd like to vertically-center the text.
I have discovered that I can temporarily get the effect I want with the following code:
(add-text-properties (point-min) (point-max)
'(line-spacing 0.25 line-height 1.25))
However, in some modes the properties go away in regions where I start typing. How do I make that top and bottom spacing the default? (Hooks won't work.)
Update
TLDR: I've succumbed to the fact that you can't really reliably achieve this natively with Emacs. You need to patch the font itself to include extra spacing. So, I created this script to take care of that.
Old/Incomplete Answer
TLDR: Add this somewhere in init file:
;; Set the padding between lines
(defvar line-padding 3)
(defun add-line-padding ()
"Add extra padding between lines"
; remove padding overlays if they already exist
(let ((overlays (overlays-at (point-min))))
(while overlays
(let ((overlay (car overlays)))
(if (overlay-get overlay 'is-padding-overlay)
(delete-overlay overlay)))
(setq overlays (cdr overlays))))
; add a new padding overlay
(let ((padding-overlay (make-overlay (point-min) (point-max))))
(overlay-put padding-overlay 'is-padding-overlay t)
(overlay-put padding-overlay 'line-spacing (* .1 line-padding))
(overlay-put padding-overlay 'line-height (+ 1 (* .1 line-padding))))
(setq mark-active nil))
(add-hook 'buffer-list-update-hook 'add-line-padding)
Increase or decrease the line-padding value to your liking.
This answer pretty much just summarizes the information in the above question, answer, and comments, so I suggest reading those first.
I use an overlay instead of text properties because it behaves more nicely when adding new text to the buffer (especially via copy/paste).
The buffer-list-update-hook is used as a means of identifying when a new buffer has been created and thus would need to have the overlay applied.
For performance reasons, to not continuously add overlays, the existing padding overlay is deleted if it aleady existed.
As the doc says, line-height is a text (or an overlay) property. It is not a variable.
Try (setq-default line-spacing 20).
line-spacing is a frame parameter or a buffer-local variable. Its value can be an integer number of pixels or a floating-point number specifying spacing relative to the frame's default line height. The doc says nothing about giving it a list value, such as (32 64).
And if you are using Emacs in terminal mode then none of this applies. As the doc says about that:
On text terminals, the line spacing cannot be altered.
Try "Help => More Manuals => Emacs Lisp Reference" and from there type i text properties RET. This will hopefully clarify the situation. As for your specific request, I don't think there's a simple way to get what you want right now. You might like to M-x report-emacs-bug about the display appearence of the paren-highlighting.
I've been using the emacs that is bundled with the Mac OS X Terminal and it is fine, but it is an older version. I like it because I can easily control the entire Terminal font size in OS X easily.
I installed the most recent version of emacs which appears to be a different animal. It's a pseudo-gui with buttons and it is outside the Terminal environment. I've been trying to figure out how to adjust the font size of the screen with no luck. Anyone can help?
Maybe I'm dumb but I rather prefer the text-only nature of the older emacs version I was using. Trying to force a menu/mouse system in there seems to go against the primitive beauty of the system.
Your basic reference for font customization is: http://www.emacswiki.org/emacs/CustomizingFaces
If you don't want to do customization via the emacs customize feature (I don't care for it myself), then this question has a good answer: How to set the font size in Emacs?
As for the gui jibba jabba, here's what I have in my .emacs:
(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))
(if (fboundp 'tool-bar-mode) (tool-bar-mode -1))
(if (fboundp 'menu-bar-mode) (menu-bar-mode -1))
Turns all of that off. :-)
edit:
I suggest using the same emacs file and have a test for the NextStep libraries used in the GUI....
(when (featurep 'ns)
;; do GUI stuff like font fiddling
)
Type this:
M-x text-scale-adjust
Then you can use the key:
+: Increasing the default face height by one step.
-: Decreasing the default face height by one step.
0: Reset the default face height to the global default.
I'm using auto-complete-mode which I think is totally fantastic. I'm also a big fan of linum-mode but I've got a very irritating issue when the two are used together, especially when I'm working in a new buffer (or a buffer with very few lines).
Basically the buffer is 'x' lines long but when auto-complete kicks in it "adds" lines to the buffer, so linum-mode keeps switching, for example, between displaying line numbers on one column or two columns, depending on whether auto-complete is suggesting a completion or not.
So you type a sentence and you see your buffer's content frantically shifting from left to right at every keypress. It is really annoying.
I take it the solution involves configuring the linum-format variable but I don't know how.
Ideally it would be great if my linum-format was:
dynamic
right-aligned
considering there are 'y' more lines to the buffer than what the buffer actually has
My rationale being that auto-complete shall not suggest more than 'y' suggestion and that, hence, the two shall start playing nicely together.
For example, if 'y' is set to 20 and my buffer has 75 lines, then linum should use two columns: because no matter where I am auto-complete shall not make the buffer 'bigger' than 99 lines.
On the contrary, if 'y' is still set to 20 and my buffer has 95 lines, then linum should use three columns because otherwise if I'm near the end of the buffer and auto-complete kicks in my buffer shall start "wobbling" left and right when I type.
I'd rather not hardcode "3 columns wide" for linum.
I guess using "dynamic but always at least two columns" would somehow fix most annoyances but still something as I described would be great.
P.S: I realize that my 'fix' would imply that linum would always display on at least two columns, and I'm fine with that... As long as it stays right-aligned and use 2, 3 or 4 columns depending on the need.
Simply put the following line in .emacs which resolves this issue. It is in auto-complete.el.
(ac-linum-workaround)
I've written a couple of previous answers on modifying the linum-mode output, which you could probably adapt to your purposes.
Relative Line Numbers In Emacs
Colorize current line number
Edit: Here's the most basic version of that code (also on EmacsWiki, albeit somewhat buried), which doesn't modify the default output at all, but uses the techniques from those other answers to be more efficient than the default code. That's probably a more useful starting point for you.
(defvar my-linum-format-string "%4d")
(add-hook 'linum-before-numbering-hook 'my-linum-get-format-string)
(defun my-linum-get-format-string ()
(let* ((width (length (number-to-string
(count-lines (point-min) (point-max)))))
(format (concat "%" (number-to-string width) "d")))
(setq my-linum-format-string format)))
(setq linum-format 'my-linum-format)
(defun my-linum-format (line-number)
(propertize (format my-linum-format-string line-number) 'face 'linum))
Just have the same problem, after seeing 'patching the source' I believe it could be done with advice. Here is what I come up with
(defadvice linum-update
(around tung/suppress-linum-update-when-popup activate)
(unless (ac-menu-live-p)
ad-do-it))
I would like to use popup-live-p as mentioned but unfortunately it requires the variable for the popup, which we couldn't know in advance.
Update:
I ended up patching the source for linum.el. I added an extra hook that runs before updates.
Here's the patched file: linum.el (github)
Here's the code I have in my init.el:
;; Load custom linum.
(load-file "~/.emacs.d/linum.el")
;; Suppress line number updates while auto-complete window
;; is displayed.
(add-hook 'linum-before-update-hook
'(lambda ()
(when auto-complete-mode
(if (ac-menu-live-p)
(setq linum-suppress-updates t)
(setq linum-suppress-updates nil)))))
Hope it helps!
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.
The problem goes away if I scroll the torn line numbers off screen and back in.
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!
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.
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'.
This is how I have it setup in my .emacs and I don't have the problem, although I also don't use emacs with gtk or any other gui.
(linum-mode +1)
(setq linum-format "%d ")
You might want to hack around with (setq linum-format) to see if you can get good results. Also don't forget to browse emacswiki on linum.
The problem was still here on emacs 24.4, OS X 10.10.1.
The solution I worked out:
after loading the theme of your choice:
(load-theme 'whatever)
(set-face-attribute 'fringe nil :background (face-background 'default))
I am using emacs 23 on my Ubuntu netbook edition. Every app, automatically goes to fullscreen (so does my emacs). But depending on the font size (:height), I get a smaller working window.
If I go to :height normal I get the full area but the fonts are HUGE!
any ideas?
Your window manager is broken. emacs resizes itself when you change the font size (this happens during startup). Your window manager should tell emacs that emacs was resized by the window manager, at which point everything will work normally.
Anyway, start emacs as "emacs --daemon" and connect with "emacsclient -c" and you should not notice this problem.
OK, so actually I added this to my initfile:
(add-hook 'after-make-frame-functions
(lambda (frame)
(progn
(add-to-list 'default-frame-alist
(cons 'height
(/ (x-display-pixel-height)
(frame-char-height)))
(add-to-list 'default-frame-alist
(cons 'width
(/ (x-display-pixel-width)
(frame-char-width))))))))
and now the window is the same size as the full screen. If you are setting your fonts inside of the after-make-frame-functions hook then it is important that this comes first in your initfile, (I think because hooks are run in reverse order) but if you're just setting the fonts then this should work OK anywhere.
Of course for maximum safety you could put this and your 'set fonts' stuff into the same defun, with this coming after the fonts have been set.
EDIT:
This is a slightly more forceful way to do it, in case that doesn't work.
This gives me some issues though, really you would probably want to subtract the height of the top panel from the height you're setting it to.
(add-hook 'after-make-frame-functions
(lambda (frame)
(progn
(set-frame-height frame
(/ (x-display-pixel-height)
(frame-char-height)))
(set-frame-width frame
(/ (x-display-pixel-width)
(frame-char-width))))))
The font size issue can be fixed simply by selecting a different size font as the default font (Options->Set Default Font), then saving the options (Options->Save Options). Emacs seems to have issues with font point sizes matching system sizes (there's discussion about X standard DPIs versus GTK standard DPIs), but if you select one that works it will stay the same.
To get the window to come up maximized correctly, I've found there's an issue with the frame alist not accounting for the minibuffer correctly as well as the different font sizes not triggering the frame to resize correctly. If you set the initial-frame-alist to include (fullscreen . fullwidth) and (minibuffer-lines . 1) it accounts for the minibuffer size correctly and comes up with the correct width, forcing an effect as if you resized the window by hand to the maximum visible area (not quite the same as maximizing). You can set these via Options->Customize Emacs->Settings Matching Regexp... Then typing initial-frame-alist. Set two new parameters and values, "minibuffer-lines" to "1" and "fullscreen" to "fullwidth".
Removing the "minibuffer-lines" parameter will give you a full screen width window that's the wrong height, and removing the "fullscreen" parameter means nothing resizes correctly. Attempting to set "fullscreen" to "fullscreen" gives the same issue as setting nothing, and "fullscreen" to "fullheight" gives blank space only across the height and not the width when a smaller font size is used.