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".
Related
In VSCode on Mac, I can use the keyboard shortcut Cmd + D to select the next occurrence of my currently highlighted text.
For example, if I highlight the variable order on line 1 in the below code, hitting Cmd + D causes order_form on line 2 to be partially highlighted, and hitting Cmd + D again causes order to be highlighted on line 3.
1. order = "Some string"
2. order_form = create_form()
3. return "Here is your order: " + order
However, I just want to select the actual variable order on lines 1 and 3 (i.e. excluding the text that is part of the variable order_form)
What keyboard shortcut can I use to just highlight the actual variables named order on lines 1 and 3?
The Ctrl+D functionality uses the current Find widget settings "behind the scenes" - whether that Find widget is visible or not.
So you would get the behaviour you want if the Whole Word option was enabled in that Find widget first before you began Ctrl+D'ing.
Alternatively, as the demo below shows when you place your cursor on the word you want order you can then hit Alt+W which will toggle the Whole Word option on and off. Note the little box that opens in the top right of the editor that shows only the Find options.
Then all your find next occurrences with Ctrl+D will find only what you want with that Whole Word option still enabled.
If you want to skip any of those occurrences, you can use the command
Add Selection To Previous Find Match
editor.action.addSelectionToPreviousFindMatch
(which you would have to make your own keybinding for). Just trigger that command to skip the next possible match - so follow this order:
Ctrl+D on the first order
Alt+W to enable whole word matching
trigger the command Add Selection To Previous Find Match
Ctrl+D to select the next order
It sounds like a bit of a hassle but they are common commands to know - to skip the next match and to toggle Whole Word matching.
[That little box that opens with the Find options is a little glitchey in that it seems to sometimes also enable the case sensitivity option as well - which isn't a problem in your example.]
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.
In Neatbeans, unindent works as expected when multiple lines are selected. But consider the following, where the pipe character | symbolizes the cursor position in the editor:
(a) Cursor at start of line (no selection)
|hello world!
(b) Cursor inside of line (no selection)
hell|o world!
In Netbeans, when I hit Shift+Tab on version (a) then the indentation is removed. This is what I expect.
However, when I hit Shift+Tab on version (b) then nothing happens. This is different from the code editors that I am used to. I would expect the indentation to be removed, or that the cursor moves to the start of the line, such that the next Shift+Tab will remove the indentation.
Is there a config in Netbeans that makes unindent via Shift+Tab work when the cursor is inside the line?
To shift the line to the left, regardless of the cursor position you can use the "Shift line left" editor action. In the default NetBeans mapping this is assigned to Alt+Shift+KP_LEFT and Alt+Shift-LEFT
Just open the keymap options page and search for the action "shift line"
It's not exactly what you are asking, but you could try to remap that action to "Shift-Tab" and see if it works.
TLDR: There seems to be a bug in the way NetBeans handles indenting/unindenting.
I would expect the indentation to be removed
I don't see any formal documentation on how unindenting is supposed to work in NetBeans, but it appears to move the text to the right of the cursor to the left, as long as there is only whitespace to the left of the cursor. While that is different to how unindenting works in other code editors such as Intellij IDEA and Eclipse, where the entire line is shifted to the left even when the cursor is poitioned within the text, it's not necessarily incorrect.
If you want to unindent in NetBeans there are two simple alternatives: either position the cursor at the start of the line, or select some text - anything at all! - on that line before unindenting.
Some comments in the NetBeans Bug Report Bug 212353 - Shift+Tab (Delete tab) shortcut does not work in editor may be relevant:
Please note that those actions should be inverse - I mean when you
select a block and you hit <TAB> <TAB> <Shift-TAB> <Shift-TAB> you
should always end up with the same text. The same should be true if
you change the order to <Shift-TAB> <Shift-TAB> <TAB> <TAB> you
should end up with the same text.
That said, NetBeans is not adhering to that standard. Using your second example, pressing <TAB><TAB> works fine, but subsequently pressing <SHIFT><TAB> does nothing, so it is not possible to "end up with the same text". That looks like a bug (in Apache NetBeans 11.2 at least). You can raise a bug report here.
It's also worth noting that <Shift> + <Tab> is actually defined as the keymap for "Delete TAB" rather "unindenting".
Is there a config in Netbeans that makes unindent via Shift+Tab work
when the cursor is inside the line?
I don't think so. All you can do, using Tools > Options > Keymap, is to change the shortcut keys from <Shift> + <Tab> to something else, but that won't change the behavior.
I currently configure my zsh tab completion with:
autoload -U compinit && compinit
zstyle ':completion:*:default' menu select=0
zstyle ':completion:*:default' select-scroll 0
What I like about this is:
unambiguous completions get completed immediately
ambiguous completions get expanded as far as possible (first strike of tab) and ambiguities get listed to me (second strike)
hitting tab further (one more tab stroke after the list appeared) I go through the menu-select'ions, i.e. the prompt stays above the list of ambiguities, one of them gets highlighted and it is inserted in the prompt, and hitting tab further, I go to the next item. Even in case the list of ambiguities cannot be displayed, then the list below the prompt scrolls.
What I don't like:
if the list is too long to be displayed, it gets first printed completely and the prompt ends up below the list, and only with the next stroke, I end up at the top of the terminal again for the menu-select mode.
So I'd like to change the behaviour to:
unambiguous completions get completed immediately
ambiguous completions get expanded as far as possible (first strike of tab) and ambiguities get listed to me, ALWAYS below the prompt, even if the list is too long to be shown completely (doesn't matter if first or second stroke)
hitting tab further (one more tab stroke after the list appeared) I go through the menu-select'ions, i.e. the prompt stays above the list of ambiguities, one of them gets highlighted and it is inserted in the prompt, and hitting tab further, I go to the next item. Even in case the list of ambiguities cannot be displayed, then the list below the prompt scrolls.
A crucial aspect is that the list of ambiguities gets shown before the first one is inserted into the prompt. Otherwise I could already use
zstyle ':completion:*:default' menu select=0 yes=0
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.