I'm using a custom modeline and I'm starting to get how to configure it but here I'm stuck as to how to get the info I want: I'd like to show, in each buffer's modeline, the width in characters of the buffer.
I'm also using linum-mode (with always at least two columns used) and ideally I'd like to deduce the number of characters used by linum from the width.
The function (window-width) is what you're looking for, this doesn't include the characters used by linum-mode however you can get their width from (window-margins)
Related
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.
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...
I'm trying to write a function that does something based on Emacs's current window width. The problem is, Emacs is confused about how wide a column is. It seems to be basing its calculations on the original font size and not my custom set one. Here is a screenshot to illustrate:
It seems to work correctly when I remove my custom font setting, so I think it must be not updating how big it thinks a column is after switching to a new font.
Here's the relevant part of my visual config:
(setq default-frame-alist
'(
(font . "-apple-Ubuntu_Mono-medium-normal-normal-*-17-*-*-*-p-0-iso10646-1")
(width . 130)
(height . 45)))
(obviously the frame was resized from my defaults in the picture, but this is where my font gets set so it seems relevant)
And here's the function I used to determine the computed current width:
(defun get-window-size ()
(interactive)
(message "The width is %d." (window-body-width)))
According to the docs, the window-body-width function should return just the editing area, so any discrepancy between column number and total frame size should be eliminated...
How do I make Emacs update its understanding of column width after changing font?
The "line&column" position indicated is based on the number of characters (tho some characters can count as 2 columns or more, TAB being a common example) rather than based on their visual display size. Different lines can use differently sized fonts, so different lines will reach the right margin at different "columns". In contrast the window sizes are counted in "number of standard-size char-cells" where the size of that standard char-cell depends on the default face (i.e. the font you specified in your default-frame-alist) used for that frame.
In your screenshot, I see nothing that obviously explains the discrepency, tho: you seem to be using a normal monospaced font and all the text uses the same font, and you don't seem to be using something like text-scale-increase, so I'm not sure exactly why you're seeing what you're seeing.
Actually, I want to generate a XPM-format image and draw it on the mode line using display attribute of a text string. However, the height of mode line turns to be different as the result of different fontset.
That means I need to know the height of the emacs mode line and use it to generate the corresponding size of the XPM-format image, so that the generated image can fill the mode line totally.
My question is just showing as the title, how can i know the actually (finally rendered) height of the mode line after applying a specific fontset?
I have searched the emacs documentation via apropos, what I found now is:
I can use the font-info function to get the font height in current frame. I guess maybe I can get what I want based on this, although I am unlucky until now.
And, I cannot find any function related a the mode line height.
Try
(- (elt (window-pixel-edges) 3)
(elt (window-inside-pixel-edges) 3))
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.