How to change the color of some outer or inner border? Whenever I change border-color of the frame, I don't see any changes and it is not allowing me to change the border width.
So far, what did work was
(set-frame-parameter (selected-frame) 'internal-border-width 15)
which adds some frame around the buffer.
But I don't know how to change the inner color. Does anyone know how to have a nice border/frame around the working space?
Any method goes.
EDIT: Added what sds accomplished:
I would like actually to have area around it to have a different color, so outside of the red.
I found an example (read: this is what I was after all along) of a frame I would like to accomplish.
It does appear that you cannot change the border width of an existing frame, but you can create a new frame with the border width you want:
(frame-parameter (make-frame '((border-width . 10))) 'border-width)
==> 10
However, the appearance of the new frame does not differ (as far as I can tell on ubuntu) from that of all the other frames (where border-width is 0);
which, I guess, is not all that surprising given that the window manager may not pay attention to [the border-width] you specify.
The more relevant question, I think, is what are you really trying to do?
Do you want Emacs windows (known as frames in the Emacs world) to differ visually from all the other windows?
If this is what you are after, then you have to realize that window decorations are the domain of the window manager (as mentioned above), and applications (like Emacs) can only affect those using "hints", and window managers are free to ignore them.
However, you can change the parameters of the fringe face:
(set-face-background 'fringe "red")
which should make the Emacs frame appearance very distinct.
I think you are specifying the fringe. You can set the fringe colour with this in your colour-theme function if you are using one.
(defun color-theme-whatever ()
"A color theme"
(color-theme-install
'(color-theme-whatever
((fringe ((t (:background "#111" :foreground "#444"))))))))
Related
I wan to change the width of emacs which can fit the width of LCD.
In addition to the details in the thread that #lawlist posted in his comment, the simplest way to get fullwidth is to set the frame parameter accordingly. The following will do it:
(set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
However, to have this happen automatically at startup, you should set the parameter in your initial-frame-alist somewhere in your .emacs file:
(setq initial-frame-alist
'((fullscreen . fullwidth)))
Beside elisp methods given in thread mentioned by #lawlist in the comment you can also set emacs geometry in ~/.Xdefaults file, eg.:
Emacs.geometry: 100x29+-2+-2
These four numbers represent width, high and position of upper left corner (optional)
Now just run xrdb ~/.Xdefaults and from now on emacs will always start with this geometry.
The good thing about .Xdefaults method is that you can set in one place parameters (not only geometry) for different programs but using similar syntax, for example
! geometry
Emacs.geometry: 100x29
xpdf.geometry: 80x25
xterm*geometry: 70x20
! foreground color
Emacs*foreground: white
xpdf*foreground: black
xterm*foreground: light grey
! background
Emacs*background: #445566
xpdf*background: white
xterm*background: #262729
! other stuff
xterm*toolBar: true
xpdf*urlCommand: /usr/bin/firefox %s
I am using Emacs -nw in Ubuntu. I like to turn on linum-mode to see line numbers on the left margin, but the numbers are put right next to my code.
I would love it if there could be some 'padding', like 1-character long, between line number and code. sorry I can't post an image since they are asking for 10 reputation, which I dont have:(
How can I do this?
You can use the variable linum-format to achieve this. Its value can either be a format string or a function which is called with line number as an argument. emacswiki has a couple of example of setting it to a format string
1) The following adds a space after the line-number
(setq linum-format "%d ")
2) You can also add a solid line separator
(setq linum-format "%4d \u2502 ")
I guess the above are sufficient for your needs. You can also find an example of using a function as linum-format here. Add whichever format suits your needs to your init file
In addition to the other answer(s) in this thread, options for putting distance between the line numbers and the text include, but are not limited to, adjusting the fringe width (and also set the color if you so choose).
The fringe is like a vertical ruler that runs from the top to the bottom of the buffer -- the left fringe is sandwiched between the line numbers and the text. It can be invisible if it is the same color as the default background of the user, or it can be a different color.
(setq-default left-fringe-width 10)
(setq-default right-fringe-width 0)
(set-face-attribute 'fringe nil :background "black")
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'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.
I use maxframe.el to maximize my Emacs frames.
It works great on all three major platforms, except on my dual-head Mac setup (Macbook Pro 15-inch laptop with 23-inch monitor).
When maximizing an Emacs frame, the frame expands to fill the width of both monitors and the height of the larger monitor.
Obviously, I would like the frame to maximize to fill only the monitor it's on. How can I detect the resolutions of the two individual monitors using elisp?
Thanks,
Jacob
EDIT: As Denis points out, setting mf-max-width is a reasonable workaround. But (as I should have mentioned) I was hoping for a solution that works on both monitors and with any resolution. Maybe something OSX-specific in the style of the Windows-specific w32-send-sys-command.
I quickly scanned the reference that you provided to maxframe.el and I don't think that you're using the same technique that I use. Does the following code snippet help you?
(defun toggle-fullscreen ()
"toggles whether the currently selected frame consumes the entire display or is decorated with a window border"
(interactive)
(let ((f (selected-frame)))
(modify-frame-parameters f `((fullscreen . ,(if (eq nil (frame-parameter f 'fullscreen)) 'fullboth nil))))))
Does customising `mf-max-width' work? Its documentation:
"*The maximum display width to support. This helps better support the true
nature of display-pixel-width. Since multiple monitors will result in a
very large display pixel width, this value is used to set the stop point for
maximizing the frame. This could also be used to set a fixed frame size
without going over the display dimensions."
This sort of thing is the job of your window manager, not the job of emacs. (For example, Xmonad handles full-screen emacs just fine.)