Let's say I use Go to Symbol in Editor. Let's further say I have a function def run(): (this is Python) that I want to jump to.
If I type #run in the Symbol search dropbox, the viewport will shift to def run in the source code.
So far, so I good. I have found what I want!
At that point, if I press esc I jump back to my starting location, rather than staying at def run() in the source. I have to remember to press Enter to get out of Go to Symbol in Editor... and stay at my location.
How can I make it so esc, by itself, always leaves me where I have found the symbol in the text?
I.e. I want to get more the behavior I get from using Edit, Find where esc leaves at the pattern location. And pressing Enter when in Find mode jumps me to the next pattern hit, if any.
environment: macos, vscode 1.63.2 (latest as of now)
p.s. You also get the same behavior from a Go to Line/Column... dialog, esc will yank you back to your starting point, Enter will leave you at the new location.
I'm afraid it's not currently possible. I've tried to unbind every single keyboard shortcut bound to Escape key so it should basically become a dead key, yet even with this setting symbol suggest highlight were cancelled by pressing the Escape, so no luck.
Unbinding the primary action is normally prerequisite for changing default behaviour -- in your case for mapping it to "accept highlighted symbol" action (which I haven't found either) -- so it seems that Enter/Escape behaviour of symbol palette is not exposed for remapping.
Related
I hate that when I'm using my laptop on its own I often type FN+v when I mean to paste. So I decided to solve my problem with AHK. I installed a keyboard hook in my main script,and used that to extract the fn keys value, 163. My initial test worked, but adding the & to make it a modifier does not. What am I overlooking?
So this doesn't work
SC163 & v::
MsgBox, %A_ThisHotkey% was pressed.
return
but this did work
SC163::
MsgBox, %A_ThisHotkey% was pressed.
return
When you hit the FN key, it might be remapping the "v" to something else (like "Media_Play_Pause" button) in the keyboard driver. Therefore the key code wouldn't be SC163 & v but something like SC159.
The Special Keys section for mentions a method to get the Scan code:
Ensure that at least one script is running that is using the keyboard hook. You can tell if a script has the keyboard hook by opening its main window and selecting "View->Key history" from the menu bar.
Double-click that script's tray icon to open its main window.
Press one of the "mystery keys" on your keyboard.
Select the menu item "View->Key history"
Scroll down to the bottom of the page. Somewhere near the bottom are the key-down and key-up events for your key. NOTE: Some keys do not generate events and thus will not be visible here. If this is the case, you cannot directly make that particular key a hotkey because your keyboard driver or hardware handles it at a level too low for AutoHotkey to access. For possible solutions, see Special Keys.
If your key is detectable, make a note of the 3-digit hexadecimal value in the second column of the list (e.g. 159).
In EMACS the default seems to be to 'copy' any text highlighted with the mouse. I'm attempting to replicate the functionality of modern text editors, where I can highlight a section of text and press 'paste' to replace it. I have so far added
(delete-selection-mode 1)
to my init.el
The problem is, if I copy something, then highlight to paste in its place, I end up pasting what I had just highlighted, changing nothing.
What do I need to change to fix that behaviour?
The most powerful element of emacs is its introspection features, lets have a look at how we can use them to try and solve this problem. We must use the power of the source.
One of the most important tools for introspection in emacs is the describe-key command which is bound to C-h k. It brings up the documentation of whatever keystroke is called after it. So in our case if we press C-h k and then click and drag we will see the documentation for <down-mouse-1> and more importantly for <drag-mouse-1>. The documentation states that "<drag-mouse-1> at that spot runs the command mouse-set-region". Below it then gives some documentation for this command. It says
Set the region to the text dragged over, and copy to kill ring.
This should be bound to a mouse drag event.
See the ‘mouse-drag-copy-region’ variable to control whether this
command alters the kill ring or not.
Now we know that somehow mouse-drag-copy-region controls whether or not the highlighted text is copied.
If we follow the link of that variable it tells us the default value and some documentation:
If non-nil, copy to kill-ring upon mouse adjustments of the region.
Now all we have to do is set the variable to be nil to get the effect that you want. Place the following code at the end of your init file and you should be all set
(setq mouse-drag-copy-region nil)
I hope that this helps you with this problem and that more importantly it helps you with further issues.
By default, selecting a region with the mouse does not copy the text to the kill ring. If your Emacs does this, you probably have set the variable mouse-drag-copy-region.
In a fresh Emacs (24.5 started using -Q), you can do the following:
Start delete-selection-mode.
Mark a region using the mouse. Copy it using M-w.
Mark a second region. Replace it with the first using C-y.
I see two alternatives, neither of which does exactly what you request. (For both, yes, turn on delete-selection-mode.)
Use the secondary selection for the text to copy, and use the primary selection (the region) for the text to be replaced.
You copy text into the secondary selection using the Meta key plus the mouse - for example, press and hold Meta (the Alt key, usually) while dragging or double-clicking mouse-1.
You paste the secondary selection using Meta plus mouse-2.
Select text with the mouse, then copy it to the kill-ring using M-w. Then select the text to replace with the mouse and use C-y to paste the copied text to replace it.
Until recently, when I typed
x=1;
2*x;
x
into the command window (without pressing enter after x) and pressed the arrow up key, the line was completed with the last command in the history that started with the already typed part, here the first line. Recently, the behavior changed to replacing it with the last command that contains the already typed part, i.e. the second line in the example, without me knowingly changing any setting.
How do I get the old behaviour back? In "Perferences->Keyboard->Shortcuts" (as per this question) the up key is associated with "Cursor up" and "Previous History Command", but the description of the latter is ambiguous regarding the expected behaviour when something is already typed into the command line.
First, make sure that the command history window is docked (If you have a floating window every time you press up then it is not docked. There is a drop-down menu - little circle with a triangle inside. Open the menu and select "Dock").
Once\if the window is docked, open the menu again and make sure that "Match Beginning" is selected and not "Match Anywhere".
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.
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.