I am trying to copy/paste several lines of code, but it appears that the behavior for this has changed and I'm not sure how to correct this.
When I select multiple words (cursor on each word). Copy. Place the same number of cursors somewhere else. Paste. Instead of pasting one word with each cursor, it is pasting all words where the last cursor is located.
Versions:
VS Code Version: 1.39.2
Commit: 6ab598523be7a800d7f3eb4d92d7ab9a66069390
OS: Linux x64 4.15.0-65-generic (Elementary OS 5.0)
Is there a setting that I am unaware of? I haven't found a setting that affects this.
And any search I do is a variation of this question. The answer in this question shows the desired/expected behavior.
When you select multiple words (cursor on each word). Copy. Place the same number of cursors somewhere else in a series (as you state in your example). Paste.
Ctrl + Shift + V
This also work is when you place the cursor on different line as well (same number of cursor as copied)
I submitted a bug to VS Code and #alexandrudima helped me find the answer.
Both workarounds suggested worked for me, but I also found that Ctrl+Shift+V, #KamalHalim's answer, worked as well.
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.
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.
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.
Let's suppose I have the following code:
But I change my mind and I don't want to call it plan anymore. I want to call it schedule. So, because VS Code is so amazing and I'm so lazy, I press Ctrl + D hoping for VS Code to change the name respecting the case. But suddenly:
Is it there any way to tell VS Code to respect the case?
With 1.37 (July 2019), it is possible through a find/replace (which now can replace by preserving case).
Issue 9798 has been implemented by PR 78003.
issue 78397 has been implemented by PR 79111 (1.38 only) for search/replace.
From 1.37 release notes:
You can now preserve case when doing replacement in the editor's Find widget. The feature is turned on when the Preserve Case option (AB button) is turned on in the editor's Replace input box.
Currently VS Code only supports preserve Full Upper Case, Full Lower Case, and Title Case.
Shortcuts are Alt + C for case sensitive. There is a little toolbar appears at the top-right corner of the VS Code, to let you toggle search options.
or you just Ctrl + F to toggle replace mode.
The v1.38 release in early September will extend the Preserve Case functionality to replacements while searching across files using the Search Panel. See add Preserve Case to Searches (all files).
.
There is also a new case preservation mode for hyphen-separated words.
v1.39 is adding preserve case for _underscore separated words. Like foo_bar.
See https://github.com/microsoft/vscode/pull/79660
If you want to achieve this without using the find/replace menu, there is an extension which solves your problem: https://marketplace.visualstudio.com/items?itemName=Cardinal90.multi-cursor-case-preserve
As far as I know it isn't, a workaround could be using the buttons that appear on top right after you press Ctrl + D. The second lets you select occurrences respecting the case, this way you could replace the text in 2 steps, first Plan and then plan.
So select the code bit, ctrl+h to open replace, edit find and replace, turn off match case in find, turn on preserve case within replace, Alt+L to find all occurences in selection, and Ctrl+Alt+Enter to execute.
9/10 cases you'll get it wrong, doesn't worth the effort. Just use ctr+d, then do the same for the uppercase.
Personally looking forward for a simpler/safer solution through the ctrl+d way. :)
I'm using (global-linum-mode t) to present line numbers in Emacs.
This works just fine up-until I use the ctrl + up/down commands (forward-paragraph and backward-paragraph) to navigate a buffer, at which point some line numbers are rendered incorrectly (see attached image).
This occurs only when I use said commands to skip entire segments of code, and the issue immediately disappears (the line numbers are rendered correctly, that is) if I start navigating the buffer by other means.
The issue is present in both C and C++ modes (visualized), and I'm using Emacs 24.3.1 on x86-64 Fedora 19.
While the go-to-line command serves my purposes in terms of navigating compilation errors and warnings, I'd like to keep the line numbers as I find them to be helpful in terms of quickly approximating length of functions.
So far I've found no mention of this problem elsewhere, and I'm unsure of whether or not this is expected behavior of Emacs or if I'm to submit a bug report.
Has anyone encountered the issue or know anything of its origin?
Fix:
The problem may be resolved by invoking (linum-update-current), as portrayed by #lawlist in his answer below. An easy way of repeatedly doing this is to append the command to the execution of forward-paragraph, which may be done using the Emacs Lisp advice feature:
(defadvice forward-paragraph (after forward-paragraph-linum-update)
"Perform (linum-update-current) after jumping forward one
paragraph to ensure line numbers are being rendered
correctly."
(linum-update-current))
(ad-activate 'forward-paragraph)
A few of the lead members on the Emacs development team suggest that linum-mode be avoided for a variety of reasons, and instead they suggest using nlinum-mode: http://elpa.gnu.org/packages/nlinum.html
I personally use a modified version of linum-mode, and I have fixed a few bugs -- if you keep using linum-mode, you will likely need to do the same -- i.e., implement your own bug fixes as you find them. The quickest way to fix the bug you see is to follow your command with:
(linum-update-current)