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.
Related
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.
I'm facing a very bizarre behaviour. No matter how I set ac-auto-start, be it through customization, by evaluating (setq ac-auto-start 2), (setq-default ac-auto-start 2) or (setq-local ac-auto-start 2) immediately after I do it, the variable is set to nil.
I've looked through the source of auto-complete mode and the ac-slime in my case, but none of these does nothing to this variable. I am at a loss as to how to deal with this.
The effective consequences of this malfunction is that completion combobox doesn't appear on its own, unless I force it to by doing M-x auto-complete. This behaviour is consistent in all modes where auto-complete minor mode is enabled.
EDIT
This seems to be an issue with latest Emacs. Now it fails to modify variables values, no matter what variable it is. So, say, after running it with -Q I've now discovered that I can't evaluate the code that uses (setq ...) forms as it has no effect. :/ So, please, hold on, I'll try to investigate this...
This was due to the typo, but the original problem is still there.
Emacs version is 24.3.50.1 pulled from trunk about a week ago.
auto-complete is version 1.4 installed from MELPA.
I'm setting the variable by moving the point to the REPL buffer, then M-:. I check its value in the same way.
EDIT2
OK, I finally found the reason: I had enzyme package installed, and it had an earlier version of auto-complete inside of it, for some reason parts of the auto-complete code were loaded from there and other parts from the one installed from MELPA. After disabling enzyme it all works well now.
EDIT3
This still happens after I run (auto-complete-mode 1) in the REPL buffer. The variable will become impossible to set. I've searched through various autocomplete timers that may be setting something, but no luck so far.
There is indeed something strange going on with the setting of auto-complete-mode.
(I'm using the ELPA version in a GNU Emacs 24.3.1)
This is set up by customize-group RET auto-complete :
'(ac-auto-show-menu t)
'(ac-auto-start t)
At this point if you M-x auto-complete-mode you get a [no match] right in the minibuffer. Only after you try to M-x auto-complete, yelding a "auto-complete-mode is not enabled" weird error, will you be able to M-x auto-complete-mode (but without command completion... Hm) and then be in the mode.
If you put this in your init file (.emacs)
(require 'auto-complete)
(auto-complete-mode t)
It will be effective only if you re-eval it after startup (?!?).
The same with something like
(if (auto-complete)
(auto-complete-mode t))
The only way that I found to get auto-complete-mode to load at startup is to :
(eval-and-compile
(require 'auto-complete nil 'noerror))
(The above customize options are now effective)
Emacs 23.2 in emacs-starter-kit v1 has C-x C-i (or ido-imenu) (similar to Sublime Text's Cmd+R). Emacs24 in emacs-starter-kit v2 lacks this function. I found this github issue and a fix, which try to recreate the functionality. While this ido-imenu works in elisp-mode, it stopped working in ruby-mode. I get:
imenu--make-index-alist: No items suitable for an index found in this buffer
Has anyone figured out how to get this to work?
Why was this taken out of Emacs24?
Is there a new replacement for this function?
Since the function is part of ESK (as opposed to something budled with Emacs) you'd probably do best to report the bug upstream. On a related note ESK main competitor Emacs Prelude offers the same functionality (bound to C-c i by default) and it seems to be working fine with ruby-mode in Emacs 24. Here you can find more on ido-imenu.
So I finally figured it out, after reading the Defining an Imenu Menu for a Mode section on emacs-wiki again.
Short answer: you need to add this bit to your customization. Feel free to add more types to the list (I am happy with just methods).
(add-hook 'ruby-mode-hook
(lambda ()
(set (make-local-variable imenu-generic-expression)
'(("Methods" "^\\( *\\(def\\) +.+\\)" 1)
))))
Longer answer: I first tried to define a ruby-imenu-generic-expression function and set that to imenu-generic-expression by using the ruby-mode-hook:
(defvar ruby-imenu-generic-expression
'(("Methods" "^\\( *\\(def\\) +.+\\)" 1))
"The imenu regex to parse an outline of the ruby file")
(defun ruby-set-imenu-generic-expression ()
(make-local-variable 'imenu-generic-expression)
(make-local-variable 'imenu-create-index-function)
(setq imenu-create-index-function 'imenu-default-create-index-function)
(setq imenu-generic-expression ruby-imenu-generic-expression))
(add-hook 'ruby-mode-hook 'ruby-set-imenu-generic-expression)
This however did not work (I would get the same error as before). More reading of the Defining an Imenu Menu for a Mode section showed me the way. Now, I'm not an elisp expert, so here's my hypothesis: basically, the above method works for modes where the
major mode supports a buffer local copy of the “real” variable, ‘imenu-generic-expression’. If your mode doesn’t do it, you will have to rely on a hook.
The example for foo-mode made it clear how to do it for ruby-mode. So it appears that ruby-mode does not have a buffer-local copy of the real imenu-generic-expression variable. I still can't explain why it worked in Emacs 23.2 (with ESK v1) but does not on Emacs24, but hey at least I found a working solution.
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)))))
I have two Emacs (Aquamacs and text-based Emacs) on my Mac.
In my .emacs file, I can check if I'm using Aquamacs with ...
(boundp 'aquamacs-version)
How can I check if I'm using text based emacs?
EDIT
Jürgen Hötzel's answer works, but for text based emacs, using
(unless (null window-system) ...)
is better as (window-system) is not defined.
M-x emacs-version
ad some more characters here......
Sorry, from .emacs, just call
(emacs-version)
I know this question was answered a long time ago, but I found another answer by typing emacs --help. This gives a list of options in which you can find emacs --version.
In my case, emacs --version prints: GNU Emacs 24.3.1.
I have only tested this solution on Linux with my current version of Emacs. I do not know if the same solution applies to Windows, or to older versions of Emacs, but in theory it should.
(if (window-system)
"window-based"
"text-based")
Or, you could use this:
(if (or (eq window-system 'ns)
(eq window-system 'mac))
(message "hello, world!"))
It will only print "hello, world!" when you run a graphical Emacs in OS X.
Errr... (not (boundp 'aquamacs-version)), perhaps?