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.
Related
Is there a proper predicate for determining whether the window has focus in the mode line? I'm trying to do some things in my mode line that require more flexibility than just using mode-line-inactive.
I've been doing:
(defun window-has-focus-p ()
"When called in eval sexp in mode or header line template,
returns true if this is the active window."
(eq
(frame-selected-window)
(get-buffer-window)))
And it worked very well on two of my computers for months (Windows 7 and Debian). However, I tried using it on another Debian box yesterday and it reported t in every mode line for every window... totally broken.
I haven't been able to find a standard predicate call for this purpose, and I can't figure out why this hacked-up one seems to work on some devices and not others. Additionally, I did evaluate (force-mode-line-update t) with M-: and that did not help.
Emacs version is 24.3
While the mode-line-format is evaluated for a given window, this window is temporarily made the selected-window. In Emacs<=24.3 this was made only halfway: selected-window was changed, but not frame-selected-window. This meant that temporarily (frame-selected-window) was not equal to (selected-window) and breaking this (normally) invariant was a source of various corner case bugs. So we fixed it in 24.4, which means that your code broke.
To make it work in 24.4, you need to save the "selected-window" as seen by the user before the mode-line-format is processed.
You can do that with
(defvar my-real-selected-window nil)
(add-function :before pre-redisplay-function
(lambda (_wins) (setq my-real-selected-window (selected-window))))
So you can then use my-real-selected-window in your mode-line-format to know which window is the one that should be highlighted specially.
I have been using this in my configuration
;;; active modeline detection hack
(add-hook 'post-command-hook
(lambda ()
(when (not (minibuffer-selected-window))
(setq powerline-selected-window (selected-window)))))
Maybe the post-command-hook is not the most elegant solution, but is working correctly for me.
I have linum-mode enabled globally in my Emacs configuration. Being enabled globally means it is also applied to the speedbar which is undesirable.
The only suggestion I found for this issue, was in the archived Emacs help mailing list, which suggests the following speedbar-mode-hook:
(add-hook 'speedbar-mode-hook (lambda () (linum-mode -1)))
Unfortunately adding this to my configuration doesn't have the desired effect and the speedbar still has line numbers.
Edit: the above add-hook seems to work correctly after all, at least for Emacs >= 24.3. Leaving question for reference purposes since there isn't any other relating to this matter on StackOverflow.
You can use speedbar-before-popup-hook hook for achieving what you want:
(add-hook 'speedbar-before-popup-hook (lambda () (linum-mode -1)))
I am not sure why the generic mode hook is not working, though.
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)
I have found it annoying that flyspell seems to stay in the middle of the word when you do flyspell-auto-correct-word command. Can this be changed to force it to go to the end of the word after running the command? It might be as simple as setting a key binding to auto-complete-word and then move-forward-word which I know how to do. But this won't work in all cases because sometimes it puts the cursor behind the word if the auto-complete word was smaller than the typed word. Any help on this would be great.
Try this code:
(eval-after-load "flyspell"
'(defun flyspell-ajust-cursor-point (save cursor-location old-max)
(when (not (looking-at "\\b"))
(forward-word))))
Tested with flyspell version 1.7k, and with the version shipped with Emacs 23.2.
I looked through the (defun flyspell-auto-correct-word ...) and I can't see any good hooks or other customization points there so I think your best bet is to use C-h f defadvice:
(defadvice flyspell-auto-correct-word (after flyspell-forward-word activate) (flyspell-goto-next-error))
Is it possible to pass a "-yes" flag to the 'recompile' command in emacs?
Excuse my complete lack of (e)lisp know-how. I got sick of going outside Emacs to compile my latex code, so i added the following key binding to my .emacs:
(global-set-key (kbd "<f12>") 'recompile);
Is it possible to automatically answer 'yes' to the following prompt that might appear:
"A compilation process is running; kill it? (yes or no)."
Also, is it possible to make the window that opens and shows the output to scroll to the bottom automatically. The interesting stuff is typically down there. Maybe its possible to chain the following command after recompile: "C-x o, end-of-buffer".
Thanks!
Here's some code to solve your first problem (interrupting the current compilation):
(defun interrupt-and-recompile ()
"Interrupt old compilation, if any, and recompile."
(interactive)
(ignore-errors (kill-compilation))
(recompile))
For your second problem (scrolling the compilation output), just customize the user setting compilation-scroll-output.
This behaviour is governed by the compilation-always-kill global variable. Customize it via customize-variable and set it to t.
Not sure which version of emacs first had this, but 26 and newer certainly does.
I somehow need to put kill-compilation into a ignore-errors with Emacs 23.2 to get it to work when no process is running. Otherwise works great.
(defun interrupt-and-recompile ()
"Interrupt old compilation, if any, and recompile."
(interactive)
(ignore-errors
(kill-compilation))
(recompile)
)
Whenever I tried using kill-compilation with latex/pdflatex it did not work. I assume it is because latex does not respond to SIGINT.
Instead I am using the following hack, which first sets the process-kill-without-query bit of the compilation-buffer and then closes it (which kills the running process).
(defun interrupt-and-recompile ()
"Interrupt old compilation, if any, and recompile."
(interactive)
(ignore-errors
(process-kill-without-query
(get-buffer-process
(get-buffer "*compilation*"))))
(ignore-errors
(kill-buffer "*compilation*"))
(recompile)
)
The other solutions didn't work for me for the same reason as sfeuz, but I didn't like the nuclear option of killing the hardcoded buffer by name.
Here's a short solution that autoanswers yes to that specific question by advising yes-or-no-p:
ftp://download.tuxfamily.org/user42/compilation-always-kill.el
(source: http://www.emacswiki.org/CompilationMode)