Enlarging text while having line numbers enabled covers the view of the numbers?
I've enabled line numbers globally by adding (global-linum-mode t) to init.el.
Zooming in on text using the C-x C-+ keybinding results in the behavior seen below, which is not satisfactory.
What can I do to fix this? Are their working alternatives?
I don't see this problem, using library zoom-frm.el (see also Emacs Wiki page Set Fonts).
But vanilla Emacs clearly has another bug, in that enlarging the text by scaling enlarges the horizontal space used for the line numbers (good), but shrinking the text then does not shrink that space used for line numbers (bad). I've just now filed Emacs bug #24164 for this.
Related
I would love to have some space between the line numbers and the first intendation/code in the VS Code editor window:
I just want to indent the code in the editor without actually adding whitespace in the code.
I tried "editor.glyphMargin", but this will only increase the space on the left of the line numbers, not between the line numbers and the code.
I'm also aware of the "Centered Layout" view, but this also decreases the width of e. g. the tabs for the file selection.
Is there a setting I'm missing or do I need a plugin/custom CSS?
You can try this --
"editor.lineDecorationsWidth": 25,
This increases the space on the right side of the numbers. I haven't seen anything that increases the padding on the other side of the gutter nearest your code.
Opinion --
Ideally, there would be a editor.padding.left like there is a editor.padding.top, but I haven't seen this yet.
I would like to change (or hide entirely) the "bent arrow" character that appears in the Emacs fringe (both on the left and right hand side). I'm using Emacs 24 on a Mac, installed via homebrew. I find it to be visually distracting. A smaller character, like a center dot, might work well.
For context, this is an official description of the small bent arrows (from http://www.gnu.org/software/emacs/manual/html_node/emacs/Continuation-Lines.html):
Sometimes, a line of text in the buffer—a logical line—is too long to fit in the window, and Emacs displays it as two or more screen lines. This is called line wrapping or continuation, and the long logical line is called a continued line. On a graphical display, Emacs indicates line wrapping with small bent arrows in the left and right window fringes. On a text terminal, Emacs indicates line wrapping by displaying a ‘\’ character at the right margin.
The Emacs LineWrap Wiki page does not address my question.
The best information I've found so far is contained in this StackOverflow answer:
When word-wrap is set to nil in a text terminal (-nw) Emacs, the backslash character appears on the right margin.
When word-wrap is set to t in a text terminal Emacs, the backslash character is not shown. Setting visual-line-mode also sets word-wrap to true.
This does not apply when Emacs is running as a GUI window: the small bent arrow appears on the right margin regardless of the value of word-wrap.
Is hiding or changing the bent arrows possible? If not, an answer that says, more or less, "I've looked at X and concluded that it is impossible" is ok too.
Update: Although it is not a terrible work-around, changing the fringes is not what I'm looking for: I want to customize the "bent arrow" character or bitmap.
First, some quick context. From Emacs Fringe Bitmaps: "Fringe indicators are tiny icons displayed in the window fringe to indicate truncated or continued lines, buffer boundaries, etc."
You cannot replace the curly arrow with arbitrary text. According to lunaryorn's answer to "Is It Possible To Replace Fringe Bitmaps With Text in Emacs?":
No, it is not. Fringe “bitmaps” are really bitmaps, that is vectors of 0/1 bits, overlayed over the fringe. There is no way to directly render arbitrary unicode characters onto the fringe. [...] What you can do, is to render a unicode character into a 0/1 bitmap yourself.
Like it says, you can change the bitmap. Fringe Bitmaps contains a list of fringe bitmaps; left-curly-arrow and right-curly-arrow are the ones relevant for this question.
Here is what I drew up. Adjust to your liking. Put this in your Emacs init file.
(define-fringe-bitmap 'right-curly-arrow
[#b00000000
#b00000000
#b00000000
#b00000000
#b01110000
#b00010000
#b00010000
#b00000000])
(define-fringe-bitmap 'left-curly-arrow
[#b00000000
#b00001000
#b00001000
#b00001110
#b00000000
#b00000000
#b00000000
#b00000000])
More documentation is available at Customizing Bitmaps, including set-fringe-bitmap-face which "sets the face for the fringe. If face is nil, it selects the fringe face. The bitmap's face controls the color to draw it in".
I am facing a strange problem. After I change the KDE window rules for emacs according to http://www.emacswiki.org/emacs/KdeMaximized, that is, I created a special window setting:
the size of echoarea (the area shared with minibuffer) is doubled by default whenever the font size is larger than 115 (1/10 pt):
,
while normally it should be like this:
Moreover, this only occurs when emacsclient is maximized and without menubar (it is fine when fullscreened or not maximized or with menubar). Maybe it is just a problem with KDE? But I couldn't find other way to fully maximize KDE without creating special window settings.
Surely a workaround is to set font size to be at most 115, but that looks too small on my 13.3 ultrabook and I usually set it to 125.
So I am just wondering if there is a way to resize the EchoArea (or change the font size of EchoArea.) by emacs settings? I tried adjusting the font size of the minibuffer, but it does not work since only the minibuffer font is changed while the Echoarea is not affected.
I am using emacs 24.3.
Thanks!
Explanation
Emacs cannot fully use arbitrary screen sizes because it (for the most part) displays a grid of characters.
As a simple example, consider characters that are each 10 by 10 pixels, and screen real estate of 1024 by 768. You'll have four pixels of width and eight pixels of height that cannot be used by Emacs.
The article you linked to is about forcing Emacs into a particular screen size. From the page:
Once you try to maximize the window, emacs resizes itself to a slightly smaller portion of the screen. This is because emacs rejects the geometry given to it by KWin, because it’s not an integral multiple of the width/height of one character.
When you tell KDE to force a particular size, the Emacs frame ("window" in non-Emacs terminology) will be the size you want, but the windows inside it ("splits" in non-Emacs terminology) may not fit properly. This usually leads to "wasted space" at the bottom of the screen like you are seeing.
As you noticed, changing your font size can give different results. If your character width is 8 pixels, for instance, you won't have any wasted horizontal space since 1024 divides by 8 evenly (128 times).
Similarly, going fullscreen and enabling the menubar both alter the amount of vertical space that Emacs has available for its windows.
Workaround
One workaround might be to adjust the size of your KDE taskbar. I believe it can be adjusted with single pixel granularity. If you adjust it smaller by a few pixels one at a time you should find a small adjustment that will make Emacs use its space more efficiently.
A you suggested, you might try to alter the font size of the minibuffer:
(add-hook 'minibuffer-setup-hook 'my-minibuffer-setup)
(defun my-minibuffer-setup ()
(set (make-local-variable 'face-remapping-alist)
'((default :height 0.9))))
(via Altering the font size for the Emacs minibuffer separately from default emacs?)
This will make the font size just a bit smaller. Try playing with the height and see if it can resolve the issue...
Update
This problem disappeared after upgrading from Mountain Lion to Mavericks, while also updating Emacs from 23.4 to 24.3.
End-update
With a .emacs file containing
(set-foreground-color "white")
(set-background-color "black")
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1) ((control) . nil)))
(setq mouse-wheel-progressive-speed nil)
as I scroll up or down with the reduced step, I see the strange patterns
Magnifying one of the patterns reveals
This problem has been present in Emacs 22, 23, and now 24 for several versions of OSX—up to and including Mountain Lion. Is it a known rendering bug? Is there a fix?
Neither the suggestion to modify fringes nor linum works for me. Where else can I look?
If I use the default white background and black foreground, these lines either do not appear or are imperceptible (to me).
What is most pesky about this problem is that redrawing (C-l) does not result in clean text.
The problem is related to the interaction between OS X's LCD Font Smoothing algorithm and the algorithm that emacs uses to implement scrolling.
The figure below shows font smoothing turned off (left) and on (right). You will find this setting in System Preferences \ general. In both cases I scrolled the program by one line. When OS X draws the "#" with font smoothing turned on, it does not only use the pixels dedicated to the "#" but also uses the blue pixels of the adjacent (blank) character.
When emacs scrolls, it only modifies the characters that it believes need to be modified. If the character is blank and will remain blank after scrolling, it does not modify it. This optimization remains valid in 2013. In other words, testing that two characters are blank is still cheaper than drawing one character. But this optimization is hardly necessary today, and it results in the buggy display.
If the hypothesis above holds, the sequel question becomes whether one can turn off the optimization. Is it possible to ask emacs to redraw the full screen at each scroll or to at least redraw characters that remain blank if they were adjacent to a non-blank character.
One could of course simply turn off font smoothing. The magnified image may even suggest that the non-smoothed image is better. In practice, when the fonts appear in their natural (unmagnified) size, smoothing makes the characters far more legible, eliminating the need to use larger fonts.
The pattern on either side of "c();" in the image below is consistent with the bug. OS X uses blue pixels on the left side and red/tan pixels on the right (possibly this is related to the RGB pattern on the display). The vertical lines left over when scrolling are either blue or red/tan/brick, depending on whether they have dropped out of the left or right side of scrolled characters.
Update
The problem is now solved in this nightly. The magnified c(); produced by Emacs 24.3.50.1 shows that the font smoothing remains identical to that produced by Emacs 24.3.1. But the output is not identical. There is at least one extra horizontal line of pixels between each two lines of text.
I don't know if this can easily be done with Emacs (read below for my hack in case there's no easy way to do this) so...
How can I add one pixel of vertical-spacing between each line under Emacs?
I know that screen real estate is precious but I'm using a "custom" font (ProggyFont) and, under IntelliJ IDEA, I can modify the vertical spacing to something that I like.
Under Emacs, however, I find the text hard to read because the pixels from one line are too close from the pixel of another line, so I'd like to add one "one pixel" empty vertical line between every line. Can this be done simply?
If there's no "simple way", how do I take a "x by y" bitmap font and turn it into a "x by (y+1)" bitmap font? I don't mind using a font editor: been there, done that. But I don't know exactly everything that would be involved.
Check out the line-spacing variable, e.g.
(setq line-spacing 0.2)
From the docs:
Additional space to put between lines when displaying a buffer.
The space is measured in pixels, and put below lines on window systems.
If value is a floating point number, it specifies the spacing relative
to the default frame line height. A value of nil means add no extra space.