Emacs has a built-in rst-mode, but the header highlight literally makes it unreadable. Is there some quick fix for this?
The screenshot above is produced on a Mac OS X using iTerm2, with emacs -Q command (which means no customized .emacs will be used). I am using emacs version 24.4.1.
To find out the name of a face, put your point on it and call
describe-face. This tells you that it is rst-level-1. Looking at
the value, you probably want to change 'Background'.
(custom-set-faces
'(rst-level-1 ((t (:background "white")))))
See the face customization
node in the manual for more details.
Related
I'm trying to get doremi working in emacs. Specifically, at this stage, to allow me to quickly scroll through a condensed list of color-themes and see each theme as I go through it. For this I would use the 'M-x doremi-color-themes+' command.
What I've done:
Installed color-themes (successfull)
Installed doremi.el, doremi-cmd.el, ring+.el and added
(add-to-list 'loadpath "~/elisp/themes")
(add-to-list 'loadpath "~/elisp/doremi/")
(require 'color-theme)
(color-theme-initialize)
(color-theme-classic)
;; create a list of color themes to scroll through using 'doremi-cmd
(setq my-color-themes (list 'color-theme-classic
'color-theme-retro-green
'color-theme-gray30
'color-theme-subtle-hacker
'color-theme-jonadabian-slate))
(require 'doremi)
(require 'doremi-cmd)
(require 'ring+)
to the .emacs file.
What emacs does:
When I type the comand 'M-x doremi-color-themes+' into the mini-buffer it seems to accept that I've given it a valid command and tells me to use the and arrow keys to move through the list. But when I do that all that happens is the cursor moves up and down in the active window. No changing of color-themes.
Being somewhat new to emacs (and especially customising it) I'm sure I have missed a step or put something in the wrong place. Perhaps there's some sort of (setq 'bla-bla-bla (...)) I need to do?
Sorry for your trouble. Please state your Emacs version (M-x emacs-version), and your version of color-theme.el.
You do not need to require library ring+.el if you use Emacs 23 or later (its code was included in GnuEmacs 23.)
You do not need to use (color-theme-initialize) or (color-theme-classic). The former is done automatically by doremi-color-themes+.
Try starting from emacs -Q (i.e., no init file, ~/.emacs), to be sure there is no interference from stuff in your init file.
Your variable my-color-themes is not referenced anywhere. Instead of defining that variable, just customize user option doremi-color-themes. (Or leave its value nil, which means that all color themes will be cycled through.)
Feel free to contact me by email if you continue to have a problem. Or continue here, if you prefer.
[Just to be sure: you are using color-theme.el, right? There is a lot of confusion out there between Emacs "custom themes" and color themes. Do Re Mi supports both, but they are different critters.]
After a bit for back and forth with #Drew we found a solution to the problem.
It turned out the major problem was that I was using emacs in 'terminal mode' rather than as a GUI application. Bare in mind I'm using a mac.
In the context of Terminal, my arrow keys send escape sequences and so doremi cannot read the event as intended. So it just escapes and applies the message to the active buffer.
There is an answer.
By adding the following lines to my .emacs file (or whatever your init file for emacs is) I was able to redirect doremi to use two other keys. ie. not the up and down arrows.
(setq doremi-down-keys '(?n))
(setq doremi-up-keys '(?p))
Doing this tells doremi to use 'n' as the down key and 'p' as the up key. And all works just fine.
Because I am only new to the world of programming and computing I may often use incorrect terminology. If this is the case please let me know and I will edit accordingly for clarity and consistency.
I recently made the switch from OpenSUSE 12.2/KDE to Fedora 19/Gnome; my .emacs has stayed the same. In particular, I am using
(display-time-mode 1)
On KDE, this worked beautifully to provide me a "mail" update whenever my Fetchmail daemon grabbed new messages. However, now on Gnome, I only get a biff notification when I have just started emacs, or when I re-evaluate my .emacs file. I have tried this in both emacs and emacsclient, and neither seems to automatically provide biff anymore; I'm not sure what's changed (emacs version is probably different, but why would a newer version break this?). Help, please!
Pertinent code from .emacs:
;; Clock & Biff display
(setq display-time-24hr-format t)
;; display-time-mode mail notification
(defface display-time-mail-face '((t (:background "red")))
"If display-time-use-mail-icon is non-nil, its background colour is that
of this face. Should be distinct from mode-line. Note that this does not seem
to affect display-time-mail-string as claimed.")
(setq
display-time-mail-file "/var/mail/torys"
display-time-use-mail-icon t
display-time-mail-face 'display-time-mail-face)
(display-time-mode 1)
GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of 2013-08-14 on buildvm-15.phx2.fedoraproject.org
Tripleee was correct: although I had fixed most of the paths across my .gnus and .fetchmailrc, I had missed these crucial lines:
nnmail-spool-file "/var/mail/[my user]"
display-time-mail-file "/var/mail/[my user]"
Obviously, those are the key lines for getting it to work properly.
The title is pretty self explanatory.
I would like to change the comment colour from black to green in lua-mode.
I've tried putting this into .emacs
(set-face-foreground 'font-lock-string-face "red")
But it didn't work. Any ideas?
If you put the cursor in the comment, and type M-x customize-face RET, it will offer to customize the correct face automatically (in this case font-lock-comment-face as Rupert mentioned). This gives you a nice way to play around with different changes to the face (to get exactly the right color etc.) and then save it to your .emacs. This is the easiest way to find out any face that you want to change.
At least on my version of Emacs, if I call describe-face on a bit of a comment in a Lua file, I get font-lock-comment-face, rather than font-lock-string-face. Have you changed the wrong variable?
I've solved it.
Uninstalled emacs 23
apt-get remove emacs
Followed the instructions from: https://launchpad.net/~cassou/+archive/emacs
Installed emacs-starter-kit: https://github.com/technomancy/emacs-starter-kit
Installed lua-mode with M-x package-install RET lua-mode
Restarted, and loaded a lua file. Now both single and multi-line comments have the same comment color and I can change it by setting font-lock-comment-face color which by default is brickred, to darkgreen according to Ivan's answer above.
I'm using Emacs 23.2.1 from Ubuntu 11.04. I've installed purcell's port of the Solarized color-theme, but I'd like to adjust some of the faces to make my Python buffers look more like the Solarized Vim screenshot. It's easy enough to edit the color-theme so that my preferred colors are always used, but that would also change them in C mode and I want to avoid that.
Specifically, here's the default setting for the builtin-face:
(font-lock-builtin-face ((t (:foreground ,green))))
In Python mode - and only Python mode - I'd like to use this instead:
(font-lock-builtin-face ((t (:foreground ,blue))))
I'd ideally like to make this change by patching some logic into the color-theme definition so that I can send my adjustments upstream with a note saying "this changes just the Python highlighting". Failing that, I'd settle for something in my init.el. I'd much rather have it packaged with the main color-theme, though.
Is this possible? Scratch that. This is Emacs; I know it's possible! But how can I do it?
This should be possible using Face Remapping. Even though you prefer to patch up the color-theme definition, I'd argue for putting something like the following lines into your init.el file, as it is a more "standard" way of doing such things:
(add-hook 'python-mode-hook 'remap-builtin-face-blue)
(defun remap-builtin-face-blue ()
(let ((blue "#2075c7"))
(set (make-local-variable 'face-remapping-alist)
`((font-lock-builtin-face :foreground ,blue)))))
The Emacs cperl-mode seems to get confused less than perl-mode, but the Skittles effect makes the thing unusable for me. Does anyone have or know of an example of a .emacs block that causes cperl-mode to use the colorization from perl-mode, ideally in a form readable enough that I can go back and turn back on the default colors one element at a time until I reach something I'm comfortable with?
In particular there is a hideously shade of light green used for some builtins that I find quite unreadable, and I prefer my variables to not have the leading $ and $$ and such tinted red along with the variable name. Most of the rest are merely distracting.
Press M-x customize-group RET cperl-faces RET and change coloring to your liking.
With colour themes, the problem is limited to arrays and hashes - and it turns out that that's because cperl-mode defines those faces as being bold-weight, which colour themes don't appear to affect (Solarized doesn't).
In Emacs 23.3 on Mac OS, the following restored the colours to how the colour theme defined them:
(custom-set-faces
'(cperl-array-face ((t (:weight normal))))
'(cperl-hash-face ((t (:weight normal))))
)
You can also use the 'real' perl-mode coloring by overwriting font-lock settings with those of perl-mode.
(require 'perl-mode)
(add-hook 'cperl-mode-hook
(lambda ()
(setq font-lock-defaults
'((perl-font-lock-keywords perl-font-lock-keywords-1 perl-font-lock-keywords-2)
nil nil ((?\_ . "w")) nil
(font-lock-syntactic-face-function . perl-font-lock-syntactic-face-function)))
(font-lock-refresh-defaults)))
You can change the color theme if you don't like the particular default colors.