I'm using a specialized input method (from M-x set-input-method), and quail is showing me the completion of a key sequence on the minibuffer. There happens to be only one single way to complete the sequence. Is there a way to tell emacs/quail to auto-complete at this point?
Related
I am slightly confused by the difference between keys and key-bindings in emacs after reading the first chapter of "Writing GNU Emacs Extensions" (O'Reilly book).
The chapter starts by noting that in some emacs version the keys backspace and DEL, invoke the help menu instead of deleting. In other words, they invoke what is invoked by C-h.
The chapter then goes on to show how to change this behaviour using Lisp code. This is done by binding the keystroke C-h to the delete command.
This is a bit confusing to me. In my mind DEL, Backspace and C-h are three different keystrokes (the first two consisting of a single key).
Why does remapping C-h effect what DEL and Backspace does?
I would have thought to change what backspace does for example, you would remap backspace to another command, not the keystroke C-h.
Unless remapped by a low-level keybord driver, the effect of the Backspace key is to send the character with numeric code 8, which, in certain operating systems, is exactly the same code generated by pressing Control-h. You can verify this fact by simply writing anything on a unix (or linux) shell and then pressing Backspace and Control-h: both of them have the effect of erasing the previous character, since the character with numeric code 8 is interpreted by the operating system as the control character BS, backspace, used either to erase the last character printed or to overprint it (see wikipedia). Analogously, Control-J is equivalent to the RETURN key, etc.
The same Wikipedia page describe DEL as “originally intended to be an ignored character, but now used in some systems to erase a character”.
So, when you assign a command to a keystroke you are actually assigning a command to a character code, and if two or more keys generate the same code, by pressing them you are invoking the same command.
#Renzo answered your question about how these keys are related and how binding one can seem to affect another. Here is some more information about what's going on in this particular case.
See the Emacs manual, node DEL Does Not Delete.
There you will see this, following an explanation of the problem/confusion:
To fix the problem in every Emacs session, put one of the following
lines into your initialization file (*note Init File::). For the first
case above, where BACKSPACE deletes forwards instead of backwards, use
this line to make BACKSPACE act as DEL:
(normal-erase-is-backspace-mode 0)
For the other two cases, use this line:
(normal-erase-is-backspace-mode 1)
Another way to fix the problem for every Emacs session is to
customize the variable normal-erase-is-backspace: the value t
specifies the mode where BS or BACKSPACE is DEL, and nil
specifies the other mode. *Note Easy Customization::.
See also the GNU Emacs FAQ question about Backspace invoking help. There you will see, in addition to information similar to that above, information about how to remap DEL on UNIX - use this:
stty erase '^?'
Wrt C-j and RET (not mentioned in the question, but mentioned in #Renzo's answer): The default behavior of Emacs changed in most programming modes, in Emacs 24.4.
Starting with that release, electric--indent-mode is turned on by default, which means that RET inserts a newline character and indents, whereas C-j just inserts a newline character. Prior to that release, these keys had the opposite behaviors. If you prefer the old behavior then do this, to turn off electric-indent-mode:
(when (fboundp 'electric-indent-mode)
(electric-indent-mode -1)) ; Use classic `C-j' and `RET'.
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>.
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.
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.
Can anyone advise how I can move forward (or back) by n commas in emacs?
I am trying to navigate my way through a CSV file
I am aware I can do something like:
C-u 100 M-f
but being able to do something more reg-exp like specifically on commas would be more accurate
The other thing I tried was combining C-u # and C-s , but that didn't work
It will with a keyboard macro, which you can define interactively.
C-x( -- start recording
C-s,RET -- search for a comma (the RET is important; see below)
C-x) -- stop recording
You can now execute that macro again with C-xe (and then just e for continued single repetitions), or use a prefix argument to repeat it a given number of times:
C-u 100 C-xe
Keyboard macros are tremendously useful, and can be easily bound to keys, or even added to your .emacs file in elisp form if you want to keep one for future use. See the manual for details.
edit:
More seamlessly for ad-hoc macros, you can supply the prefix argument when you stop the recording to get exactly that many repetitions, including the one used to record it:
C-x(C-s,RETC-u 100 C-x)
I was seeing some unexpected behaviour with that sequence before I added the RET to explicitly invoke isearch-exit before stopping recording. It behaved as if it was only recording and repeating the comma key (leading to the comma being inserted many times instead of being searched for many times).
Using edit-last-kbd-macro after recording, I could see there was a quirk when using isearch in a macro, such that the C-x typed when stopping the recording is actually included in the macro definition, which was presumably causing the problem for this particular method of invocation. Similarly with the alternate F3 and F4 bindings (in that case, F4 ends up in the definition). I don't know whether this is a bug or a feature, but apparently it pays to exit the isearch before stopping the macro recording!
p.s. Although the two sets of macro recording bindings aren't identical in all respects, everything here also works with F3 and F4, so for this example you could slightly more concisely use F3C-s,RETC-u 100 F4
With
iy-go-to-char you
can do M-3C-cf, to go to
the third comma.
Use CSV mode which will give you convenient functions to do what you want and more
You could record a macro with C-u C-u M-f or C-u C-u C-f and use that. If it's infrequently used, record it using PF3 and play it back by pressing PF4.