To quote emacs help, M-/ is:
(dabbrev-expand ARG)
Expand previous word "dynamically".
Expands to the most recent, preceding
word for which this is a prefix. If no
suitable preceding word is found,
words following point are considered.
If still no suitable word is found,
then look in the buffers accepted by
the function pointed out by variable
`dabbrev-friend-buffer-function'.
In other words, if somewhere in program there is a variable called reallyLongVariableName and I type reaM-/ then emacs automatically fills in the rest. If more than one match exists (ex, reallyUglyVariableName) then M-/ cycles thru them.
I believe it exists since eclipse3.1 and was tracked by bug 11668
("Add emacs-style "Alt-/" hippie auto completion").
Alt+/
Text editors now support word completion.
In text editors you can complete a prefix to a word occurring in any of the currently open editors or buffers.
The default key binding for word completion is Alt+/ (Ctrl+. on the Mac).
Note: if you repeat the Alt+/ key combination, it will cycle amongst all the word beginning with the current prefix, starting with the closest one from the current edit position.
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'.
while isearch-forward run as a command, the context I had typed will hightlight in the current buffer, but while run query-replace don't hightlight that, how can i make it hightlight?
Use isearch-query-replace. It highlights the string to be replaced.
It sounds like you are saying that query-replace does not highlight all of the matching occurrences. Is that right? It should highlight them. If it does not, then try starting Emacs without your init file: emacs -Q. If that shows no lack of highlighting then recursively bisect your init file to find the culprit.
#Rocky mentioned isearch-query-replace. That doesn't change highlighting (which should already be turned on), but what it does do is let you start query-replacing while you are isearching, using the last search string as the pattern for the text to be matched by query-replace.
An alternative to query-replace, useful especially if you have relatively few replacements you want to make and there are lots of matches, is to use on-demand replacement while isearching. For that you need library Isearch+.
To replace any given search hit on demand, just hit C-M-RET. With a prefix arg, C-M-RET prompts you for the replacement text (the default is to replace with no text, which means to delete the hit). You can thus change the replacement text anytime, within the same Isearch invocation.
After replacing the search hit, C-M-RET moves to the next one. So you can just use it repeatedly if you want to replace several successive search hits. Or use C-s to skip replacing the current hit and move to the next one.
On-demand Isearch replacement works also for regexp searching, and just as for query-replacing, the replacement text can be either inserted literally, as is, or interpreted as in query-replace-regexp. In the latter case, you can use \&, \=\N, \#, \, and \?. You can use C-M-` anytime during Isearch to toggle whether replacement text is used literally or interpreted per the special regexp-replacement constructs.
The following packages provide live highlighting and replacement previewing for query replacing, as well as additional features:
https://github.com/syohex/emacs-anzu
https://github.com/benma/visual-regexp.el
https://github.com/benma/visual-regexp-steroids.el
I currently use visual-regexp-steroids.el.
All three packages can be installed from MELPA.
Typing text in Emacs with company-mode turned on. When I stop at the end of a word company-mode shows available completions. Because the word is already written, it does not need to be auto-completed and I want to type another word, I press space key. company-mode inserts first suggestion instead of canceling auto-completion. Is this normal? How can I make company-mode to cancel auto-completion when I insert space character?
Example:
This file is
Cursor right after "is" and company-mode shows some auto-completion suggestions. After I press space key I get:
This file isearch-adjusted
("isearch-adjusted" was the first suggestion in the tooltip of company)
See the description of company-auto-complete, and set it to nil to disable this behavior.
It's nil by default, though, so it shouldn't have caught you unawares. Are you using someone else's Emacs config?
It's not that convenient when you do a typo during an incremental search and the search string receives the wrongly typed character. Is there a way to prevent this. As if control-g was pressed automatically on error.
For example we have the following text:
keywords
keys
Default emacs behavior:
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" won't be found, the cursor stays on the "keywords" line, search echo area displays "keyzs", which is not convenient
Needed behavior:
We start incremental search and search for "keyz"
The "key" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press s
"keys" is found and highlited
You could try something like
(defadvice isearch-printing-char (before drop-mismatches-on-next-char activate)
(while (or (not isearch-success) isearch-error)
(isearch-pop-state)))
Emacs keeps the incorrect part, because it happens very often that you search for a string and it is not found, but not because it's incorrect, only the search string is found before the cursor. In this case it is very convenient that you can press C-s and the search starts from the beginning of the file.
It is very useful behavior and it happens to me more often than mistyping the search string. If there is indeed an error in the search string then you can simply press C-g to go back to last good search string.
I think the problem is that you're not thinking about searching in a way that's congruent with the way isearch has been designed to work, and so your question doesn't really make sense within the context of isearch as it currently exists.
Isearch does already give you exactly the feature what you want, but you have to tell it that you want it to happen by typing that C-g you seem so vehemently opposed to typing. If you don't tell isearch what you want to do, and when you want it to do it, how is it supposed to know what to do?
As #Tom tried to explain, the default way isearch starts from the current position in the buffer, and can restart at the beginning of the buffer if you've typed some failed characters and then press C-s, is a very valuable feature. I'm sure many people rely on this behaviour. Your method of using a macro to always start an isearch at the beginning of the buffer would confound and confuse many of us, though of course it's not a bad thing for someone such as yourself who is accustomed to it. It does mean though that the rest of us are quite confused by your dislike for having to press C-g to delete the non-matching text.
Think also for a moment about what a second C-s does if you press it immediately after starting isearch (any time but the first time in a session) (i.e. before you type any other character). Note in particular what happens if your previous search string would only partly match something in the current buffer, and then you press C-g (and also note how the failed search string is presented, regardless of whether it would partly match something in the current buffer or not).
Think also about how your feature might adversely affect the use of multi-isearch-next-buffer-function.
Claiming that other editors can do what you want isearch to do in emacs doesn't really help your case much.
I think what you really want is some slightly different type of search function which only allows you to search for text that it is possible to find in the current buffer, instead of isearch's ability to search for anything whether that text happens to exist in the current buffer or not.
Perhaps isearch-mode could be adapted to do what you want it to do, but one way or another I think you'll have to write some elisp code. Perhaps you could implement your new search mode as an option within isearch-mode that can be toggled on and off in the same way case sensitivity can be toggled on and off; and that can be set by default, again in the same way that case sensitivity can be turned on or off by default.
If you make a typo during incremental search all you need to do it press backspace to correct the typo.
We start incremental search and search for "keyz"
The "keyz" is displayed in the search echo area and the "key" part in "keywords" is higlighted
We press backspace
We press s
"keys" is found and highlited
As with most of the other answers, I'm just pointing out another feature which helps mitigate the described problem. This one is particularly useful if you've continued to type several would-have-been-good characters after the bad one.
M-e is the binding for editing the isearch string, and in the case where there are no matches for the current string, it rather helpfully places point at the first non-matching character.
So if you have made a small typo, you can quickly type M-e, fix the mistake, and type RET to return to isearch using the corrected search string.
I wrote a simple function, that makes emacs add matching quotes (so when I type ", I get "{cursor}"). But now, it's a major annoyance when I delete the first quote but the second is still remaining.
Is there a way to "listen" for character deletion events, and it the next character is matching the deleted one, delete the next character as well?
There are existing minor modes for this. See AutoPairs at the EmacsWiki.
autopair.el has the specific functionality you're describing.
(electric-pair-mode in Emacs 24 does not, it would seem).
Related Q&As (mentioning autopair):
Intelligent auto closing matching characters
Is it possible to auto-complete parentheses or quotation marks in emacs?
How do I get TextMate style quotes in Emacs?
Automatically closing braces in Emacs?