After I restarted my computer, VSCode started to behave oddly. When I open any file:
The cursor's style seems to be "block", although in the settings it's "line".
If I type any character, the character doesn't get written into the file - VSCode actually deletes the character located where the cursor is
After that, I can finally write new characters and the cursor returns back to normal (a line)
Here's how it looks:
Does anyone know if this is bug on their end? I'm using VSCode#1.45.1.
Nevermind, it seems that this was caused by the Vim extension I recently installed. There's a thread opened about it.
Related
I have the following snippet in the hypersnips extension (in vscode)
snippet txt "text in math" imA
\text{$1}
endsnippet
Usually, it works fine with me typing txt and it automatically sends me to
However, sometimes when using a snippet I get the following
After this occurs, if I delete that and try again, I get
This "bug" (?) occurs 10-20 per cent of the time and it is very annoying. Moreover, it is not unique to a specific snippet.
I have tried changing the version of vscode and of the extension but nothing has seemed to work.
Any help will be greatly appreciated.
EDIT: Screenshot to address rioV8's comment
I think that it is the bug of VSCode. When you overlap placeholders more than (about) 18 times, it occurs.
Just because HyperSnips adds too many placeholders, you noticed the bug.
Test: use VSCode keybindings to add snippet (without extensions).
ctrl+M inserts $|$ | .
Click here to view the result
However I don't know why it occurs and how to solve the problem. Sorry for that.
Recently I started exploring vscodevim, and knew about the daw command, that not just deletes before the next word, but completely deletes the current word too.
Logically, dae command would delete before the end of the word, but it, suddenly, just clears the file... So, what's wrong?
In vscodevim, the motion ae refers to the entire buffer, hence dae will delete it.
Note that this has nothing to do with the "real" Vim, that's not a valid command there. I would use Gd1G to have the same effect in Vim:
G goes to the last line;
d1G deletes from there to the first line.
Although there are no doubt other ways, Vim is nothing if not prolific in the varying ways to do things :-)
Note this answer was made, when the question stated the problem as a vim problem. This answer does answer the question in a vim context, but does not have to do anything with vscode.
Well lets have a closer look at what you are doing:
daw -> Delete a word. Deletes the an object of the type word, whitespace inclusive. (there is diw -> Delete inner word, which does not delete the whitespace). This objects can be found in :h text-objects
Now you try the same with the motion e which is the end of the word. The end of the word isn't a text-object, it is a position. This is the reason a and i can't be used on de.
in vim dae is not valid. No idea what vs code makes out of it.
I am trying to figure out why VSCode sometimes decides to randomly insert "non-breaking spaces" U+00A0 instead of regular spaces, and how to stop this from happening?
This is a different type of space character which is causing issues, as seen in my previous question GitHub markdown not rendering and git detecting changes when no changes
This is happening to me on both Mac OS and Windows, and others have experienced this issue too. Although this question is about VSCode, this also happens on the online GitHub markdown editor.
How do I solve this problem?
Steps to reproduce
Edit a markdown .md file in VSCode for a while.
Put in lots of headings such as # my heading or ## my sub-heading.
If you have the markdown extension you can CTRL/CMD + SHIFT + P and Open preview to the side.
You should eventually notice that one of the headings doesn't render, and if you open the file in a hex editor such as HxD you'll notice that there is a non-breaking space instead of a regular space after the # character.
Possible causes
The backtick ` character on Windows can be combined with a letter on your keyboard for example a which results in à. Maybe the use of backticks is causing the space character to turn into a non-breaking space? However this wouldn't explain the problem on Mac OS, because backticks can't be combined with other characters.
I have this a lot too on Mac OS, but it turns out I am still holding the option key slightly (or perhaps shift on your keyboard) when typing the space after just having used the modifier key to type #
I've installed https://marketplace.visualstudio.com/items?itemName=viktorzetterstrom.non-breaking-space-highlighter&ssr=false#overview to spot my mistakes early.
I just spent quite a lot of time trying to figure out why a "mv foo bar" command I copy and pasted from VScode was returning command not found. Turned out the space in between mv and foo was a non-breaking space which I only determined by pasting it into a unicode text converter. I would really like to know why this is happening and if it's a setting I can disable. I am using Windows 10 so I don't think it's just a Mac issue.
I have faced this trouble several times when copy/pasting code from Microsoft Skype or Microsoft OneNote. Both programs convert regular spaces into special Unicode spaces when pasting into it.
By the way, since version 1.63, Visual Studio Code automatically highlights these special spaces.
I ran into this too, but I'm sure I unwittingly inserted the non-breaking spaces using the spacebar alone. I found the hexdump plugin useful for diagnosing the problem. I still don't know how to avoid it.
If I attempt to edit a previous shell command (obtained through the history keys), the cursor becomes an underscore. If the command involves a directory or filename, it is underscored already and so the cursor simply disappears.
I'm using zprezto - how can I change the cursor character or shape?
The cursor, it turns out, is set by the terminal emulator and not by the shell. So once I knew that, it was easy to make the change.
I'm switching from Dreamweaver to Sublime Text, but the way ST handles autocomplete is different from DW. In DW, the tag autocompletes when you start typing the ending tag. But with ST, it autocompletes when you type the opening tag.
My problem is that in ST, you get trapped inside the tag you're typing, and the only way to move on to the next line is to hit the right arrow key a bunch of times. That seems totally ridiculous. Is there some shortcut I'm missing?
This might be what you're looking for:
https://github.com/SublimeText/Tag
In my copy of ST with this plugin installed, beginning to type the end-tag completes the tag and moves the cursor to the character immediately following the end of line.
Ctrl Enter will bring you to the next line and keep the auto complete that shows up. I'm on a mac.