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
Related
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).
I've just found out that Hippie-expand works in the mini-buffer (via M=/), however I use smart-tab (via TAB) for completion (and indentation) during standard editing. Hitting TAB in the minibuffer only inserts 4 spaces - which is something likely I'd never actually want. Is there a way to do directly Hippie-expand with smart-tab in the mini-buffer? I have completion for paths, buffers and extended commands (through ido/smex), but would like to have it for everything (e.g. for replace, search, flush/keep-line etc.) that needs input.
At the moment I use simply (Emacs 23.3):
(setq tab-always-indent 'complete)
although in the past I had more elaborate smart-tab settings and it also didn't work in the minibuffer...
Thank you!
I don't think you need smart-tab at all to get tab minibuffer completion. You might try icomplete-mode instead:
(icomplete-mode +1)
Since smart-tab just indents or completes and in the minubuffer you never want to indent I guess it's basically the same.
Icicles gives you (TAB) completion pretty much whenever the minibuffer is used, the only exceptions being when the calling code explicitly uses the minibuffer in a way that does not allow completion.
(But when constructing Lisp sexps (e.g. with M-:), you can use M-TAB to complete individual symbols.)
It sounds easy but I can't fix it: I want to permanently disable automatic spell-checking in emacs. There must be a simple line for my init.el. Can somebody help me?
Figure out why it's on in the first place (it isn't enabled by default), then fix that. Either your init file is turning it on, or else some system-wide init file is. Read about those files: http://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html
From a brief look, the simplest way I can see is to redefine the function:
(eval-after-load "flyspell"
'(defun flyspell-mode (&optional arg)))
or you could use advice to force the argument to always be -1 (see C-h f turn-off-flyspell), but that would be slightly more complex and less efficient for no good reason.
If you want to know what is running it in the first place, you could use M-x debug-on-entry flyspell-mode, which will show a stack trace when the function is called (q to exit the debugger; C-h m to list other commands; M-: (info "(elisp)debugger") for help). Use M-x cancel-debug-on-entry to remove that breakpoint.
(flyspell-mode 0)
I found mine in ~/.emacs.d/usk/text.el
I deleted the block of code having to do with FlySpell and closed emacs.
After reopening emacs, I still saw the spelling error (red underline). However, I simply deleted and retyped the "misspelled" words and then, emacs didn't underline. Problem solved.
I'm running Debian.
In my case flyspell-mode has been gaining ground in the .emacs.desktop file.
This was not the first time that desktop-mode causes pain in restoring obsolete things. In this case it restored all modes on a per-file basis, although in .emacs.el I had already disabled flyspell-mode and flyspell-prog-mode everywhere.
Solution: either edit the .emacs.desktop file or delete it.
Using Emacs graphical mode you can just right click above "Fly" minor mode bellow and select "Turn Off minor mode" like this:
Vim completes words and lines with CTRL-X P and CTRL-L. There's a Emacs plugin called Company mode but this plugin interfere and cause conflicts with lots of things within Emacs (with global linum and yasnippets). I know that I can complete words with CTRL-/ in Emacs. But it is possible to take previously written lines to complete code?
Maybe you're looking for hippie-expand? From that web page (as of this writing, anyway):
HippieExpand looks at the word before
point and tries to expand it in
various ways including expanding from
a fixed list (like expand-abbrev),
expanding from matching text found in
a buffer (like dabbrev-expand) or
expanding in ways defined by your own
functions. Which of these it tries and
in what order is controlled by a
configurable list of functions.
For a comprehensive list of completion options visit the emacs wiki page on completion.
There are a gazillion ways to do completion in Emacs. Some are mode specific, some inline, some configurable and what not. Here is a list of modes that might help you.
Use numberic argument to complete by line, say M-5 M-/ will complete by line, while M-/ alone still complete the normal way.
hippe-expend function has a very useful feature which is :
With a positive numeric argument, jumps directly to the ARG next function in this list. With a negative argument or just C-u, undoes the expansion.
Customize the expansion functions in hippie-expand-try-functions-list and put the function try-expand-line as 5th list element, then you could use M-5 M-/ to complete by line.
This tip is very handy and useful and I highly recommend it.
Also worth noting: if your window manager does not steal Alt-tab, emacs will auto-complete with Alt-tab (I set up my window manager to user the "windows key" instead of alt for this very reason).
If you are using evil, this is the most vim-like solution I use:
(defun my-expand-lines ()
(interactive)
(let ((hippie-expand-try-functions-list
'(try-expand-line-all-buffers)))
(call-interactively 'hippie-expand)))
(define-key evil-insert-state-map (kbd "C-x C-l") 'my-expand-lines)
This way you can use our old friend C-x C-l in insert mode for whole line all buffers completion.
Thanks #ymln for the suggestion of using try-expand-line-all-buffers.
I'm using pdb to debug Python programs and am unhappy with it's behaviour.
I have the screen divided into multiple emacs windows, and when I execute pdb, it (randomly?) replaces one of the windows with the output of the *gud* debugger.
Also, when a breakpoint is encountered, even if the debugging buffer is already visible in a window, it usually puts this buffer into another window, and replaces another of my windows with the contents of the source file. (incidentally I like that it jumps to the correct line in the source file)
How can I disable gud/pdb from managing my windows for me? Is it possible in emacs to prevent all programattic manipulation of windows & screen layout?
Edit: I found the answer that partially solves this in another post: toggle dedicated windows
I tried all these approaches without success on Emacs 24.
If you are still interested I reverted to the old gdb behavior using 'gud-gdb' which implements the old behavior of gdb/emacs interaction (no dedicated-windows and no I/O buffer). If you don't want to call M-x gud-gdb when you use it, you can define an alias for M-x gdb
Look into sticky windows.
I have a solution that prevents the gdb from stealing windows. It works with Emacs 24.4 (2014-07-18 snapshot) and does not require dedicating buffers. The benefit over other answers is you won't have to bother dedicating and undedicating buffers whenever you change buffers, which quickly becomes tedious.
Place this advice in your .emacs:
(defadvice gdb-inferior-filter
(around gdb-inferior-filter-without-stealing)
(with-current-buffer (gdb-get-buffer-create 'gdb-inferior-io)
(comint-output-filter proc string)))
(ad-activate 'gdb-inferior-filter)
This effectively replaces this function as defined in gdb-mi.el and removes the branch that calls gdb-display-buffer, which is the cause of the window thievery.
You should use Sticky Windows to make your windows and buffers stick where they are but Sticky Windows won't stop gud/pdb from trying to steal your windows. When gud/pdb can't steal your source code window, it opens a new Emacs Frame even if there is another window on the current frame.
This comes from the fact that the function that tries to jump to the gud-pdb buffer (py-pdbtrack-track-stack-file) calls function pop-to-buffer with argument OTHER-WINDOW set to t.
To circumvent this behavior for all libraries that calls pop-to-buffer, you could cancel the role of OTHER-WINDOW by defining an advice on pop-to-buffer (in your .emacs) :
(defadvice pop-to-buffer (before cancel-other-window first)
(ad-set-arg 1 nil))
(ad-activate 'pop-to-buffer)
You should also customize variable pop-up-windows to nil in order to force display-buffer (the low-level routine used to display a particular buffer on windows and frames) to not create a new window.