Which setting needs to be done in init.el file, which allows completing the rest of command if one hit M-x and initial letter of the command.
Infact in need something similar as ido-mode for minibuffer too
The ido-mode for the "M-x minifuffer" is called smex (smex use ido).
Available on the main package repos of Emacs. Homepage here
I think you are talking about incremental completion, i.e., having Emacs automatically complete what you type in the minibuffer, without your having to explicitly request completion (e.g., using TAB).
Incremental completion is available in Icicles, as well as Ido and IswitchB. And icomplete-mode shows you completion candidates in a similar way to Ido and IswitchB.
Icicles incremental completion has two aspects:
When buffer *Completions* is displayed and updated, showing you the candidates matching your input -- how soon that happens and what triggers updating
Whether and how much your minibuffer input is expanded (completed) to reflect the set of matching completions
Wrt *Completions* display (#1):
You can use C-# to cycle among the levels (normal, eager, off) at any time.
Normal means that *Completions* is not displayed until you ask for it, but thereafter it is automatically updated as you type/edit your input.
Eager means that *Completions* is displayed as soon as you type something that matches at least two candidates.
(There is also an option to show *Completions* from the outset, before you type anything -- useful as a kind of menu.) You can also specify how long to wait after you type or delete a character before updating *Completions*.
Wrt input expansion (#2):
Icicles is unique in expanding your input to (typically) the longest common match among all completions, even when completion uses apropos matching (that is, regexp or substring -- S-TAB), not just prefix matching (TAB).
There are 4 levels/behaviors for this expansion, plus off (no expansion):
Off -- this is like Ido and IswitchB: completions are shown, but your input is not completed
On request -- expand your input only when requested (TAB or S-TAB)
On request or sole candidate -- on request or when there is only one match
Always for TAB, on request for S-TAB -- TAB expands whenever possible; S-TAB is like previous
Always -- expand input whenever possible
C-" toggles between two of the input-expansion behaviors that you choose (a user option), and C-M-" cycles among all of the behaviors.
Related
In emacs I'm already using iswitchbuffer, but I would still like to be more productive with my buffer switching.
One common case which arises a lot is that I have 6 or 7 identical or near-identical file names. For example:
server.py<proj1> server.py<proj2> server.py<proj3>... foo_server.py<proj4>
The problem is that I have to type out most of the directory context when I'm switching buffers.
An existing alternative to typing the directory context is a completion window which pops up saying:e
Click on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
... ....
but this is unsatisfactory as well since I have to the switch to the window and use the mouse to pick one.
What I'd prefer is to use tab or some other key to highlight alternative buffer selections, then enter to select one. Is there a way to do this?
In iswitchb-mode (and its successor1 ido-mode) the default binding for cycling through candidates are Ctrl+s and Ctrl+r.
You should be able to limit your candidates by typing the common bit of the filename then cycle through those candidates with those bindings.
1 See the header text in iswitchb.el and ido.el.
If you use icomplete-mode (which is a bit like iswitchb-mode but applies to all completions rather than only for buffers), you can cycle to the next/previous matching candidate with C-, and
C-..
Another option, if you use the default completion system (with or without icomplete-mode), is to type serv*1 (for example) to select server.py<proj1>.
I used to be confident of returning to buffer from mini-buffer by just pressing C-g once, until I learned there is a "recursive-edit-mode" inside Emacs Here, which seems to make cancellation action inconsistent. Therefore, I am reading the entire section in hope of finding a more consistent / stateless command to return to mini-buffer.
However, I encountered below problems when following and trying to replicate what the manual says:
Entering Recursive-edit-mode: After "M-x query-replace RET C-r" (in Fundamental-mode), I could not replicate "a pair of square brackets" in mode-line. However, now I DO have to press C-g TWICE to return back to buffer.
Question: Does recursive-edit-mode still have square brackets now? (I am using ver 24.3)
Quitting: The manual directs me to the Quitting section for quitting command. It says Aborting with C-] (abort-recursive-edit) is used to get out of a recursive editing level and cancel the command which invoked it. So I tried it out within "M-x query-replace RET C-r", hoping one C-] will get me out from minibuffer to buffer, but it still takes 2 shots to do that.
Question: Is this normal? If yes, any other command to guarantee command abortion and return to buffer with 1 execution?
Just want to brush frequently used command such as C-g. If made consistent, it may help avoid inputs being eaten (sometimes unnoticed) by the minibuffer due to trapped inside recursive-edit-mode.
Visually confirming point each time inside the buffer makes keyboard input an closed-loop feedback process and thus consumes more attention, though.
You definitely will see square brackets in the mode line for a recursive edit -- but not for a recursive minibuffer.
C-g does act consistently, but it does different things in different contexts (always the same thing for a given context, however). That can be confusing. It can take some getting used to - a bit like it takes getting used to the various behaviors of C-g during Isearch, depending on the current search state.
If you use recursive edits or recursive minibuffers then you need to pay attention to clues wrt the current state/context. Again, this is like learning Isearch. minibuffer-depth-indicate-mode is a must, to provide feedback about what state you are in.
FWIW, beyond minibuffer-depth-indicate-mode, I use a standalone minibuffer frame, and with each recursive edit or recursive minibuffer the background hue is changed slightly, to better indicate the level etc. (The background color changes slightly also for (a) active minibuffer and (b) Isearch. I use library oneonone.el for these things.)
If you don't use a standalone minibuffer frame then you might consider highlighting the square brackets or something else in the mode line, to help you tell where you are at.
C-r during query-replace is a good example of when a recursive edit can be useful. There are a few others. But generally I do not make much use of recursive edits, FWIW. (I do, however, use recursive minibuffers a lot, because I use keys bound in minibuffer maps that do invoke commands that themselves might prompt for input etc.)
Wrt your question about query-replace with C-r: There is no minibuffer involved at all, here. And C-] after C-r does end not only the recursive edit but also the query-replace (whereas C-M-c ends the recursive edit and returns to the query-replace.
FWIW - In Icicles interactions, you might find yourself within any number of recursive minibuffers. (For example, you might use progressive completion to successively narrow the set of completion candidates, and each narrowing opens a recursive minibuffer.)
C-g always aborts the current command, or if there is none then the current minibuffer, and C-] always aborts the current minibuffer. Repeating C-g (or C-]) pops back up the minibuffer chain, a level at a time. But (in Icicles) you can use C-M-S-t (aka C-M-T) to pop directly back to the top level (exit all minibuffers).
Similarly, answering a minibuffer prompt (e.g. hitting RET or using mouse-2 on a candidate in *Completions*) exits the current minibuffer, popping up a level (to the parent minibuffer or to the top level if there is none). (In Icicles RET can optionally put you back at top level.)
Currently, in C-mode, if I start typing a word such as:
namespace_module_
dabbrev-expand will cycle through a million full completions of this identifier...
namespace_module_typea_foo <TAB>
namespace_module_typea_bar <TAB>
namespace_module_typea_goo_start <TAB>
...
With many possible words, it is tedious to navigate through all of these. However, minibuffer completion seems to work differently. It only completes until the first difference among the possible matches. It would have completed to (assuming there were no other matches to something like typeb_, etc):
namespace_module_typea_
At this point, I need only type one character to remove the ambiguity, and it is very likely that autocompletion's next guess will be correct. Is it possible to use this completion mode in-buffer with dabbrev-expand? Or hippie-expand? Or even icicles? I've not been able to find anything.
Have you tried dabbrev-completion (bound to C-M-/ by default)? It should do just what you're asking.
Yes, icicle-dabbrev-completion, which by default is bound to C-M-/ (replacing dabbrev-completion) gives you what dabbrev-completion gives you, but with Icicles completion features whenever there is more than one completion. IOW, you can match using a substring, regexp etc.; you can use progressive completion; you can sort and cycle candidates; and so on.
See the doc about this, here.
I use M-. to jump to definitions of class/functions. Sometimes there are multiple classes with the same tag, so I need to use C-u M-. to jump to multiple files, hence multiple buffers. Now my question is, how do I go back to the original buffer quickly? I know C-x b, but you need to type in the buffer name, or it just give you by default the last buffer you visited, is there anyway to go further? For example, go to the previous buffer of the last buffer?
I believe that M-. calls find-tag by default. You should be able to go back up the stack of locations with M-* (pop-tag-mark).
From C-h f find-tag:
A marker representing the point when this command is invoked is pushed
onto a ring and may be popped back to with M-*. Contrast this with the
ring of marks gone to by the command.
Icicles multi-command icicle-find-tag, bound to M-. in Icicle mode, combines all of what vanilla Emacs commands M-. (find-tag), M-, (tags-loop-continue), tags-apropos, and list-tags do. And it does more.
You can complete against any tags, cycle (in different orders) among a subset of tags matching an additional pattern, and so on, visiting multiple tags in a single command invocation. You choose the tags you want to visit, in any order --- you need not visit each one in sequence.
You first enter (using RET) a regexp that all tags you are interested in must match (it could be vacuous, to get all tags).
After that, you can type a pattern that a subset of the tags and or their source files must match.
That is, by default you can complete against multi-completion candidates that are composed of the tag itself and its source file name.
You can choose candidates to visit using C-mouse-2 in *Completions* or by cycling among their names using down and up and then using C-RET to visit.
You can return to your original location using M-* (icicle-pop-tag-mark). You can also return to it by just using C-g to finish your M-. invocation.
More information here.
I use winner-mode for this (and other similar situations).
Add (winner-mode 1) to your init file, and then when you wish to return to the window configuration that you were in before jumping to the tags, you just type:
C-c<left> to call winner-undo (repeating as many times as necessary)
If you had visited multiple tags in another buffer, this will get you back to your original buffer (or the previous buffer, at any rate) in a single step, rather than stepping back through the individual tags one by one.
If the tags have taken you through multiple buffers, then you'll need to type C-c<left> once for each buffer (or C-c<left>C-xzzz... if you'd gone on quite a long detour :)
While trying to autocomplete a file (e.g. to open a file with C-x C-f) Emacs-helm shows a list of possible candidates.
If I then press Tab (which I would hope it would help me choose the first/closest match), I get the following in the minibuffer:
It looks like the minibuffer gets confused with escape characters, and it does not choose the file that I actually want to open (the top choice).
Helm requires this conceptual jump from the default Emacs completion, which is not so obvious:
You don't need to press a key to complete. The completion buffer refreshes
with new results after every input.
This is called "incremental" completion.
The normal tab functionality is not needed in "incremental"
completion. So tab was rebound to helm-select-action, which allows you to
choose an alternative action with the selection. But there is only one action
in read-file-name.
The error you're seeing could be clearer though, I've filed this issue on github.
Additionally, note Helm treats each space separated term as a filtering
regular expression. So, pressing space foo will filter
the current list down to those that contain foo in the name.