I use Emacs with Evil mode, and while I entering the search pattern, the ElDoc message is displayed replace the current search pattern. It is quite annoying. I looked into ElDoc and see a function eldoc-display-message-p that check for conditions that ElDoc should not display the message.
I need some hint to advice this function to prevent ElDoc interference with Evil search.
The function eldoc-display-message-no-interference-p is a predicate function that will determine whether or not to display an eldoc message at the time.
Searching in Evil uses isearch, so when you are searching, the variable isearch-mode will be non nil.
You can customize the behavior of eldoc-display-message-no-interference-p by editing it directly but that is often not the best choice, we can modify it's behavior instead by using "after advice". If you are unfamiliar with advice, read about it here.
(defadvice eldoc-display-message-no-interference-p (after dont-show-when-isearching activate)
"Always return nil if isearch-mode is active."
(setq ad-return-value (and ad-return-value (not isearch-mode))))
Related
I'm an evil Emacs user. However, I really only use the normal mode for fancy Vim style edits when I find them more convenient than regular Emacs commands. (Mostly fancy bulk editing/yanking/deleting). However, I'm also a huge user of the minibuffer (I do a lot of M-x with ido and flx so I can avoid remembering the more esoteric commands). When I do, evil switches to normal mode automatically after I exit. I find that very annoying/confusing. How can I get it to stop? (preferably in an elegant, non-hackish way).
Thanks,
PythonNut
EDIT:
It appears that the switch to normal mode happens in all windows and in all frames.
I cannot reproduce your issue; maybe knowing your versions could help anyone to identify your issue. Can you reproduce your issue with "emacs -q" (plus adding evil to load-path)?
Here is an approach to identify the evil (traditional English meaning) piece of code, if any, that is calling to evil-normal-state:
(defadvice evil-normal-state (before debug-issue activate)
(setq debug-on-error t)
(inexisting-function-will-fail))
Eval this just after setting a buffer in the evil-state you want it to be, then go to to the minibuffer with M-x. Is there an stacktrace?
You may reactivate evil-mode by adding whatever function you use to activate it to minibuffer-exit-hook.
Is it possible to modify function's behavior with defadvice for specific mode/buffer only? I want mouse-yank-primary to insert extra text, but only when i'm in specific mode. I've tried 'defadvice after' for mouse-yank-primary, but once activated it works in all other buffer as well.
I think it can be resolved by rebinding mouse button to my own function in mode hook, but elisp manual says it's better to use defadvice.
Rebinding the mouse button to another function seems preferable to me. You don't need a mode hook for that, usually you just modify the mode's keymap:
(eval-after-load '<mode>
'(define-key <mode>-map [mouse-2] 'my-mouse-yank-primary))
Localizing an advice to a major mode is a bit harder. There's no argument you can pass to defadvice to do that, but you can set some variable's buffer-local value in a mode hook, and then check this value in the advice code. If it's set, do something special. If not, just evaluate ad-do-it.
Localizing an advice to a major mode is easy:
(defadvice foo (after bar activate)
(when (derived-mode-p 'python-mode)
(do (something) now)))
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))
I am doing small modification to SLIME, so that I can get all currently loaded symbols from Lisp, analyze them and make font-lock fontify them.
I managed to do all these steps, but I have a small problem - when keyword list changes in font-lock the buffer is not updated unless you restart the major lisp-mode. I don't want to restart lisp-mode every time I update keywords, because I have several hooks on lisp-mode that I want to run only when I load the file for the first time.
Is there an other way to update font-lock so it reads all then new keywords and fontifies the buffer accordingly? Switching off font-lock and using font-lock-fontify-buffer does not do the trick.
UPD: Added bounty - the question is still up. I need a way to reload font-lock keyword without reloading major mode.
Ok, how about this instead:
(defun my-font-lock-restart ()
(interactive)
(setq font-lock-mode-major-mode nil)
(font-lock-fontify-buffer))
You could temporarily clear the mode hook variable and restart it:
(defun my-restart-lisp-mode ()
(interactive)
(let ((lisp-mode-hook nil))
(normal-mode)))
Triggering the major-mode is not what makes font-lock do its thing. I am not intimately familiar with the internals of SLIME or lisp-mode, but just setting the variable should make it work. Toggling font-lock-mode will make font-lock start refontifying with the new keywords in mind, as should font-lock-fontify-buffer.
I hack on cperl-mode, mostly, and it is a simple matter of cperl-init-faces (which sets the internal font-lock variables) and a restart of font-lock. lisp-mode should not be much different, except for not needing a call to cperl-init-faces ;)
Edit: some experimentation with lisp-interaction-mode reveals that even restarting font-lock-mode is not strictly necessary. Just changing font-lock-keywords is enough, as long as you re-trigger fontification somehow. (Editing text, font-lock-fontify-buffer, etc.)
As a vim convert, I've gotten fairly used to viper mode. One issue that I've discovered, however, is that viper-auto-indent breaks all inferior modes. What happens is when I enter any sort of inferior mode (sql-mode, ess-mode, etc.) and hit Enter, the Enter key doesn't actually send the command off to the inferior process and gives the appearance of the process just hanging.
Without setting viper-auto-indent I have the problem that the Enter key doesn't automatically indent when writing code, meaning that I need to always hit tab after entering a new line, which is annoying. The workaround I've been using is to have viper-auto-indent enabled by default (since I spend most of my time programming), and then disabling it when I enter an inferior-mode buffer.
Does anyone know how to fix this problem? Alternatively, can anyone help supply me with the elisp to disable viper-auto-indent when switching to an interior mode buffer, and enabling it when in a non-inferior mode buffer? Thanks.
I think Emacs' intent is to have you use "C-j" for newline-and-indent, and let Enter be left alone.
If that is not yet acceptable to you, then this untested code may work:
(add-hook 'inferior-ess-mode-hook
'(lambda () (set (make-local-variable 'viper-auto-indent) nil))
I'm not able to reproduce your problem. I tried every level of viper-mode (1-5), and a number of inferior processes. That said, from your actual question, this code appears like it should fit the bill. If/when 'viper-autoindent is called, if the current buffer has a process, it calls the original binding for the keys just pressed. If there's no process, the original viper-autoindent is called.
(defadvice viper-autoindent (around viper-autoindent-but-not-when-buffer-has-process activate)
"work around reported user problem"
(if (and (this-command-keys)
(get-buffer-process (current-buffer)))
(let* ((viper-mode nil)
(thiskey (key-binding (this-command-keys))))
(when thiskey
(call-interactively thiskey)))
ad-do-it))