I like the auto-save functionality, but don't like Emacs displaying "Auto-saving...done" every few minutes.
Supposedly, the function that does the auto saving (do-auto-save) has an optional parameter (NO-MESSAGE), but I don't know how to change that parameter without changing the Emacs code (i.e., there is no "customize" functionality to disable or change the message).
What would be the best way to disable the auto-save message without disabling the auto-save functionality?
Many thanks!
Probably the best thing to do would be to find where do-auto-save is being called and change the call, but advising the function is a lazy solution that works:
(defadvice do-auto-save (before no-message activate)
(ad-set-arg 0 t))
Related
In Emacs, I don't want the *Completions* buffer to pop up, even when I press tab to autocomplete in the minibuffer and there are multiple results.
It's distracting and jarring.
How can I do this?
Even better, I would like an alternative that isn't distracting or jarring -- such as requiring one tab for autocomplete if available, but requiring two tabs to open a Completions buffer. This way, I don't get the Completions buffer when I'm expecting an autocomplete. This is what the OS X terminal does to show tab completion possibilities.
I think the cause is the minibuffer-completion-help command, which is run automatically, described here: https://www.gnu.org/software/emacs/manual/html_node/elisp/Completion-Commands.html
I use ido and smex, but the problem occurs in a vanilla Emacs too.
EDIT: I found a hack to fix this. Using M-x find-function, I found and copied the function definition of minibuffer-completion-help into my .emacs.d/init.el file. Then, I renamed the version I copied my-minibuffer-completion-help and changed (with-displayed-buffer-window *Completions* to '(with-displayed-buffer-window *Completions* (putting a quote in front so it is just interpreted as a string. Finally, I overrode the call to minibuffer-completion-help by putting
(advice-add 'minibuffer-completion-help
:override #'my-minibuffer-completion-help)
after the my-minibuffer-completion-help function in my .emacs.d/init.el file. There must be a better way.
EDIT 2: quoting out (message "Making completion list...") in my-minibuffer-completion-help has the added benefit of getting rid of the flicker in autocomplete that is caused by flashing another message during autocomplete. Is it possible to do this another way?
I believe you just want to set completion-auto-help to nil:
(setq completion-auto-help nil)
I believe what you're looking for is either temporarily modifying display-buffer-alist, probably setting it to use display-buffer-no-window for *Completions* or M-x customize-group completion and setting Completion Show Help to nil
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.
Sometimes I use an alternative method (usually sed) to edit a file
that's already being edited by Emacs. Later, if I try to edit the file
in Emacs without reverting the changes first, I get an error message
and a prompt asking me what to do.
That's all fine. The problem is that I tend to forget very often when
I've made some parallel changes, so I'd like Emacs to
remind me by showing a red "M" in the mode-line.
I know how to customize the mode-line (by adding strings to the
mode-line-format variable), but I have no idea how to check if a
file has been modified outside of Emacs.
Is there a function to check whether an Emacs buffer is up to date
with the file it corresponds?
Try
(verify-visited-file-modtime (current-buffer))
See Section 27.6 Buffer Modification Time.
Not really a direct answer to the question, but you can avoid this problem by turning on auto-revert globally in emacs with (global-auto-revert-mode t).
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))
I've recently started using ido-mode, which, overall, is pretty nice. But one thing seems especially broken, and I'm wondering if there's a setting (ha) buried in there to fix it.
ido-switch-buffer doesn't seem to care about buried buffers. That is, if I use bury-buffer, and then ido-switch-buffer, the first choice is often the one I just buried.
Is there an easy way around this? The whole point of burying a buffer is that I don't want to see it again any time soon.
Acording to the documentation (C-h f bury-buffer)
Put BUFFER-OR-NAME at the end of the list of all buffers.
There it is the least likely candidate for 'other-buffer' to return;
thus, the least likely buffer for C-x b to select by
default.
So, if you use bury-buffer the buffer will be still available (at the end of the list), so it's normal that ido-switch-buffer find it.
If you don't want to see that buffer ever, you should think of closing it.
I can't reproduce this. On Emacs 23, as far as I can tell, ido-switch-buffer lists the buffers in the correct order.
In any case, you might try out iswitchb instead. It's kind of like ido, only older and more specific to buffer switching. If you like it, you can use iswitchb for buffer switching and ido for everything else.
can't reproduce this either: when i bury a buffer and call ido-switch-buffer afterwards, the buried buffer is NOT at the front of the switch list.
i have done quite a bit of ido customization (to get it working well with dired, etc), but my main ido settings are:
(setq ido-show-dot-for-dired t)
(setq ido-default-file-method 'samewindow)
(setq ido-default-buffer-method 'samewindow)
(setq ido-confirm-unique-completion t)
(setq ido-max-dir-file-cache 20)
my ido.el version is "1.57 released on gnu.emacs.sources adapted for emacs 22.1".
hth.
Use next-buffer or previous-buffer
FWIW, the default completion behavior of switch-to-buffer (C-x b) in Emacs-24 has been changed to use substring-match completion, so its behavior is similar to IDO while obeying the principle that "the default buffer shouldn't be the one I just buried". You can make it even more similar by turning on icomplete-mode (which does not change the completion behavior itself, but displays the completion candidates at the end of the minibuffer).