I don't know how to describe this behaivor:
Press ( key on selected text in vs2022, what i want is to replace the whole selection with (, but it does not, even worse, what it does is to add another ) to the end of the selection, this is really annoying and happened many times. i tried to find options in Tools/Options, twice, and nothing found to disable it.
(actualy, it happens to all marching symbols like "(<{, so i guess it's something to do with the brace marching thing.)
Please help, thank you.
Related
I am using VSCode Hypersnips (based off of Vi's https://github.com/SirVer/ultisnips), following this guide . See also Create-Snippets-For-Ultisnips.
Consider the following example: I have a snippet
snippet fm "inline Math" wA
\(${1}\) $0
end snippet
and another snippet
snippet ( "parenthesis" wiA
($1) $0
end snippet
If I were to type fm, then that would produce \(|\) |, where the first | is where my cursor is, and the second | is where my cursor would be if I pressed <Tab>. Now, when I type fm ( hi <Tab> that produces \((hi) |\) as expected, but when I press <Tab> again (hoping to use the $0 tab stop of the fm snippet), I don't get outside the right \) like I want, and instead a tab character (i.e. 2 spaces) are placed where the cursor is.
I am wondering if I can nest snippets like this, and still use the tab stops of the outer snippet once I exit the inner snippet.
I assume the same issue occurs if I use native VSCode snippets.
StackOverflow informs me that a similar question has been asked: Atom - Nested snippets with tab stops error, but not about VSCode's snippets.
It seems this is known issue: https://github.com/draivin/hsnips/issues/78. This is a summary of the issue from Dec. 2 2021:
So, I looked into it, the placeholder disappearance is caused by a
workaround we are currently using to get around a VsCodeVim issue.
History time:
We started using the workaround to get around this issue Trigger A leaves me in visual mode, I want it to leave me in insert
mode instead #28.
Supposedly, the related issue in VSCodeVim was fixed
here Snippet is not working Properly VSCodeVim/Vim#5240.
I'm not sure
if it was never properly fixed, or if a regression happened, but it
seems that the issue still exists (see Unexpectedly entered visual
mode in snippet VSCodeVim/Vim#7068), so while that issue is still
open, we can't remove the workaround and fix this bug.
For now, https://github.com/draivin/hsnips/issues/126 offers what I think is the best solution, namely using VSCode Neovim.
Sorry for roughly worded question.
I'll start typing something in VS Code like class="bob", and as soon as I type the opening " mark, VS Code will auto populate the closing " mark as well. Very helpful! BUT, once I'm done entering my string of information, I find myself having to adjust my keys on my keyboard to arrow right past the character that was automatically added, then hit a space, and continue on my coding way.
However this can interrupt my typing flow, as it would be just as easy if not easier for me to type the closing " mark myself without adjusting my hand from the default keyboard position.
This happens with other characters, too, not just quotes. Parentheses, brackets, single quotes, and similar items that show up in pairs.
When I watch videos of some people coding, they seem to gracefully whiz by those auto-added closing punctuation marks, so it makes me think there is something I'm missing in how I accept that automated input. Some way that is more zen like than using a right arrow.
Any guidance is much appreciated.
This worked for me;
Go to VS Code settings
Search "autoclose"
Disable "Auto Closing Tags"
Change "Auto Closing Quotes" from 'always' to 'never'
Change "Auto Closing Brackets" from 'always' to 'never'
You have several options:
Type the character that added automatically. For example, if you type { and automatically VS Code added } you can also type } to continue typing whatever you want. VS Code is smart to not doubling the automatically added character
Use End key
Use arrow right key
I think the VS Code team didn't find it needed to add some special key for this need, since all these options are also one key each.
I'm playing around a bit with DrRacket in the BSL language.
When I'm trying to create a comment like so:
;; Hi(10, 50]
The program fails in the moment when typing the ]. I can only end it via TaskManager. It uses 13 CPU in the TM.
Has anyone of you a solution for that? or is it simply not to use ].
Thank you
This is some bug that was reported several times recently, and there's no fix, yet. It's probably a result of some non-english keyboard layout (which was the case in these reports). Hopefully it will get fixed soon...
UPDATE: The bug was fixed for the next release, but in the meanwhile Matthew posted some instructions on how to do a temporary fix -- repeated here for reference:
We have tracked down a problem that occurs when the AltGr key is needed
to type ].
DrRacket gets stuck due to a bad implementation of an operation that is
intended to be bound to Alt-]. For most of you, though, the problem is
that you didn't want the Alt-] keybinding at all; you're just trying to
type ], and it's misinterpreted as Alt-].
You can work around the problem by placing the five lines at the end of
this message in a file, and then selecting the file via the
Edit -> Keybindings -> Add User-defined Keybindings...
menu item in DrRacket. Typing ] should work immediately after, and
typing [ will also give you just [ (instead of [ and ]).
Beware that after you select the file, it will be difficult to unselect
it. It turns out the the menu item to un-select a keybindings file is
also buggy! Your best bet is to put the file in a place that it can
stay. (You can still edit the file and restart DrRacket if you just
want to drop the bindings.)
I'm writing my own terminal application in C using the VTE library. Everything works great except I cannot select text with the keyboard. For example if I have just typed something, in most terminals you can hold down the shift key and select the previous text with the left arrow key, then you can paste it wherever you want. In VTE, all that happens is you get a D in the current cursor position. I can obviously block the printing of D in the terminal by returning TRUE from the keypress (which I have done), but I still cannot select the text.
I thought I might be able to do it manually starting with vte_terminal_get_cursor_position(), but there is no method to select a block of text (that I could find) in VTE once I have the boundaries for the selection.
I've looked at other VTE based projects such as tinyterm, and evilvte, but they just print the D in the terminal as well when that key combination is pressed.
So is there any way to select text in VTE using the keyboard? Thanks.
Correction:
It turns out that very few if any terminals allow you to select text with the keyboard. Not sure how that got into my head. Anyway, I still think it would be a handy capability, so the question stands. Any ideas would be greatly appreciated.
When I try to add closing parentheses, it always override the next parentheses to the right.
Here is a screen capture (it looks like I hit the right-key on the keyboard, but I'm actually inserting a new closing parentheses):
Is it possible to change this behavior?
As of version 1.38, the answer is yes, you can turn it off completely, while still keeping the autoclosing brackets.
That version introduced a new setting, editor.autoClosingOvertype, which can take three possible values:
always - always overtype closing parens (the old, classic, Sublime-Text-inspired behavior)
auto - "smart" overtype which tries to detect whether a closing paren was automatically inserted by the editor, and overtypes only those parens (this is the default)
never - never overtype closing parens
The current default behavior was introduced in version 1.37. At that time, there was no setting available, you just got the "smart" overtype behavior no matter what.
I'm leaving the material below for historical purposes.
No, it's not possible (yet), and this is by design. When you are typing brand-new code, and you type an opening bracket, you get the closing bracket automatically (when you have editor.autoClosingBrackets on, of course). Then, when you are finished with typing whatever you want inside those brackets, how are you going to "exit" and leave the closing bracket where it is? The most natural way is to type a closing bracket! Some disagree, but many typists find this much easier than moving their hand all the way out to the arrow keys or mouse to move past it.
Note that this behavior is largely inspired by and modeled after what Sublime Text does.
It may be helpful to understand that the autoclosing brackets feature isn't primarily for saving keystrokes. Rather, its main purpose is to improve the stability of syntax highlighting (which can get wonky when there is an unclosed bracket), and secondarily to help prevent you from forgetting to type the closing bracket. If you happen to navigate away for some other reason without typing it, then congratulations, you do get that bracket for free!
The two simplest options you have if you want to add a bracket (and let me note that in your example, you'd be adding a mismatched bracket) are to either (1) put the cursor after the cluster of closing brackets before you type a new bracket, or (2) put the cursor where you did, but just keep typing closing brackets until a new one is added. In either case, any new brackets will only be added to the end of the cluster.
Update (now obsolete):
For what it's worth, there's now an issue for this on the tracker, as well as a pull request to create a setting which allows you to turn off the "bracket-swallowing". For anyone who is reading this, if it's something you're interested in, you should give your feedback on the pull request.
Further update (now obsolete):
There is currently new code being tested which will make the bracket overtyping more sophisticated. The plan is for the editor to keep track of which brackets have automatically been generated, and only type over those brackets. Once the cursor leaves the bracketed area, the editor stops keeping track of those brackets and they become "full-fledged" characters that can no longer be typed over. Hopefully, this will retain the overtyping where it's useful and get rid of it where it's not. Note that the current plan is for this new behavior to become standard, and to not have a setting to control whether it is in effect.
Try setting:
"editor.autoClosingBrackets": "never"
to disable the autoclosing brackets feature entirely.
Vscode has finally fixed this issue, and you don't need to do anything in order to get the new behaviour. Now it will swallow only brackets that were automatically added, so everything works as expected. If you already disabled the autoClosingBrackets option from the settings, it is recommended to turn it on again now.
The way to work with the VSCode original setting is to add new parenthesis at the end of a list of parenthesis.
...if (test === funFunction(data))| /* <- here */ {...
You should be able to type a new parenthesis and it won't override the old one. This doesn't solve your problem, but if you wanted to follow the paradigm that VSCode is using then there you go.
(personally I disable it like the other comments say)
There's another option available now called autoClosingBrackets beforewhitespace. This will overtype an automatically added parenthesis but it will not overtype of there's any characters to the right of that closing parenthesis. This is perhaps a step closer to the OPs intended behavior, it certainly saved me from going totally bald.