jiebi/CodeConvo huggingface dataset:
Now if I go back too far, accidentally removing the opening angle bracket (<), and then re-type that character to fix my error, then the code is broken because the end-tag has been converted to a new start-tag. Now all of these are simple examples, and if you are aware of the feature and/or see the errors as they occur, it is super easy to fix the code again. Either manually or by using the undo-feature. But if the code is longer and more complex and the end-tag is out-of-view when the errors occur, it may be quite difficult both to discover the errors and to fix them.
Here is a use case where the default "on" of this new "feature" is incorrect. tl;dr - A proficient vim user can make a horrible mess very quickly with mirror cursor. I rarely use VSCode but at work I need to write up some documentation from time to time and I prefer to do so in html. So I fired up VSCode for the first time in a while and started typing up a doc. I use vim bindings and don't need to look at my editor too much especially when working in the way I was today. So I wasn't paying attention to my editor. About halfway through I opened my work in a browser to review how my old CSS settings were treating the work. It was a garbled mess of half paragraphs and repetition. Using '/', '?' and other regular vim navigators causes multi-cursor insertions EVERYWHERE. Change the default to "off" and test these features against different editing options like Vim and Emacs in the future.
This kind of falls into the same category as any setting that can help users reduce keystrokes (similar to ). When you've built up some muscle memory or expectation for how things behave, and that suddenly changes, it can take time to get used to. Personally I have many of these features disabled because of being used to unconsciously doing many of them manually, and the time investment in changing that and fixing mistakes that occur in-between hasn't seemed worth it. It can be especially frustrating when you are in the middle of something and a feature like this is introduced. Even more so if finding the name of the feature in order to disable it winds up taking more than a trivial amount of time.
The worst part is for those who are uninformed, which is everybody who didn't see the patch notes, the name of this feature would remain elusive until you either find the correct patch notes on stumble upon this thread. How can one disable a feature that has no name? Personally I thought it was a bug with multi-select / multi-cursor that got enabled on accident. Still do actually.
I'm also having issues when moving lines with alt-arrow . I want to move the starting tag higher to include block of code above, but ending tag also gets moved.
I also got hit with this today. I mangaged to edit the opening element but it did not auto select the closing element. When I then tried to edit the closing element it auto-selected the opening element parent to the first one. See picture for example. I also ran into the same issue as and by then my blood was boiling and I literaly screamed from frustration. Features like this should not be activated by default when it clearly messes with peoples personal coding behaviour/styles. !
Had four lines of elements. Selected the opening tags for all four as distinct selections, and then edited to add to each. Didn't realize it was corrupting content in the close tags. Uck. Too dangerous to use, let alone enable by default.
A use case that this feature completely corrupts is reordering HTML tags using the + key binding. It took me ages to realise that when I was refactoring some html, reordering things, why my html was all of a sudden being corrupted because the corresponding tag was being moved as well, and more often than not, incorrectly. This should definitely not be on by default. Thanks for reading.
Created a draft PR, seemed like a pretty trivial change, just need to hear if I have to do any other tests/etc for this
All the complains above explains well, and I just want to add my current brand new face to face experience, which I encountered numerous times and today I finally, "enough is enough"... ! Anyway, thanks for the hard works, to those who work with this feature... but please make it off as default... Thanks...........
I'll turn this off by default and work on , which will be an opt-in feature.
Great, it is nice to hear that it will be turned off by default
Issue Type: <bBug</bGo to menu affichage apparence afficher la barre latérale secondaire L'item indique ceci " afficher la bar&re latérale secondaire" Un petit And & se balade Have a nice day VS Code version: Code 1.67.1 (, 2022-05-06T12:37:03.389Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (3)</summaryExtensionVersion ------ copilot1.20.5902 vscode-pull-request-github0.42.0 vscode-language-pack-fr1.67.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
the translation lacks an extra ampersand to turn this into a mnemonic <img width="501" alt="image" src="https://user-"
can you ensure there's a comment that says "don't touch the ampersand"? Additionally, you can add another comment in the form of: to ensure that they do not get "translated". See this example:
I have the same comment in 275 places across the code base And this is the string
Best I can do is ask for the string to be updated manually to ensure is not translated... but that won't prevent this from happening in the future due to human error. better is using a locked comment like the one above... could also have the be a runtime string instead... but really we need language-aware mnemonics where the position of the changes based on the language but I'm not sure if there's a process for that. do you know?
so I add? what kind of enforcement does this do? does it just force that a mnemonic exists? its not really required that a translation contains a mnemonic even if the original does
I believe it forces that it exists, though or are experts here.
I know a little bit more... this does basically "fail the string" until it meets the criteria of "there should be a somewhere in the string and a translator looks at this. did you get the chance to add this to the comments?
Reported originally by where GitLens seemed to be breaking JSON auto-complete behavior -- causing an extra being at the end. ! I tracked it down to this contribution causing the issue I was able to reproduce this with a clean vscode user-dir/extensions-dir and a simple extension with that contribution
That JSON extension has configurationDefault for the setting: That configurationDefault is lost when the gitlens extension also makes a configurationDefault The bug is that all default overrides for the same language need to be merged, not set.
I do not see a duplicate of my issue: ! So I'm in the clear. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.32.0 OS Version: Windows 10 1809 Stable Steps to Reproduce: Visual Studio Code, click on the "Search" sidebar menu item to bring up the huge Search menu. ! for a common word used quite a lot. Like "a", "let", "var", "i", and so forth. the Search displays the total results count, dismiss a few of them. total results count should decrement by 1 per dismissal, or indicate both the original total results count and the remaining non-dismissed total results count side by side when dismissing the search results. For example: ! Does this issue occur when all extensions are disabled?: Yes
For me, it does decrement. You don't see that? You are clicking the 'x' icon on a result row, right?
It doesn't. !
Ok, so I was about to get it to decrement, but that's not done in real-time. ! Both of the GIFs are done in 1.32.1.
That's right, I thought you were talking about the total shown at the top ("x results in y files") in your original post.
This also happens when a new match is or deleted in an existing file match. !
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When using Copilot, users would like to be able to only partially accept suggestion instead of the whole suggestion at once. The users demand either word by word or line by line completion. Desired behaviour: Press a predefined key and accept the whole suggestion. Use a predefined combination of 2 keys to accept the top line of the suggestion. (eg: For a suggestion of 3 lines, the user would need to press the combination 3 times to accept the whole suggestion). The prompt would not show the line already accepted.
this sounds to me like a UX problem. Is there a mock sketch for a potential solution here? Is there some other editor which already supports this? We can also discuss it in one of our UX weekly meetings.
I don’t have a mock sketch. No other editors are supporting this yet but it is a requested features. I wanted to get the discussion going (doing the same for the other editors) to understand the constraints around it as well.
Technically, I think this would be rather easy to implement. I'd love to hear some more UX discussion before we implement this thought. What key-binding do you have in mind?
do you have some UX designers on your team that would like to help here? Once we have some good ux proposal we can bring it in our UX weekly sync on Wednesday to start the discussion.
No I dont have a UX designer in my team. I ll see how i can come up with a suggestion and get back to you
This is similar to Solution for me was 'CMD + -' to accept a word at a time. Something similar here would be great.
Fish shell allows word-by-word completion using the <kbdAlt</kbd+ <kbd&;</kbdkey-combo, which—at least on macOS—is used system-wide for navigating text word-by-word. I notice that I keep trying to automatically use this key-combo, so big +1 from me. ( Did not realise this is the vscode repo.) 
awesome idea. since you said this is low hanging maybe we assign to July for the initial investigation? What do you think?
This would be great.
I am loving copilot so far, but this is my biggest UX gripe. Copilot's first suggestions in a new piece of code tend to only be accurate for the first few words. It tends to get much better only after more context is . Not a blocker, but it'd make it much easier to get started.
We did an initial investigation and this is not low hanging as I have initially commented above. Also, this milestone we have been mostly focusing on improving the merge editor. So this one will have to continue in September.
Had a sync with the VS folk and here's some very early thinking: When partial completion is accepted the ghost text should not change - we should use the cache. VS did multiple user studies and users always get shocked when the ghost text changes beneath them Undo is the user gesture to undo the last partial acceptance (this should work out of the box for us). Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as and commands. Open questions (probably not for first version): How to make this keybindings discoverable Should we support the mouse? For example alt + mouse click to accept until the mouse click
I've also previously advocated for a way to accept only a single line out of the multi-line completion. I would strongly support doing this at a line granularity, rather than e.g. token granularity, since I ~never run into the case where I want to accept 'more than 0 tokens but less than a line' of a multi-line completion -- it's ~always either one line or maybe a couple, or the whole completion. Repurposing regular cursor movement commands for partial acceptance when a ghost text completion is open sounds error-prone. I see this kind of key-stealing behavior in some autocomplete systems (especially for ), but it's always optional, since it's really easy to interfere with muscle memory and frustrate people. This would apply to text navigation commands for sure, and it would be even worse in the middle-of-the-line completion case (which would also be wonky if we want an 'accept a single token' shortcut).
Hi! A use case for per-word completion: comment/natural language completion. I want this almost every time that copilot gives me a comment suggestion.
To make sure I understand the shape of the discussion, I think three issues are separable here: 1) whether to offer partial completion; 2) at what granularities (here the use case and example-based analysis is most relevant, and feed back into question 1); 3) if doing it, what default keybindings at these levels to provide so as not to hijack muscle memory (but possibly still utilize it in a parallel modifier key universe)? Is that right, and if so at what stage does the team currently see the conversation? For 3), in Lisp-y language tools, Paredit's keybindings might be a decent template too: in some sense what we are doing here is structurally selecting part of what is an (falling back on a as above) structure before "acceptance" (which is already well-understood as a result of by default keybinding users). That would be a more elaborate form of the partial acceptance, though, requiring a language-sensitive parse, so definitely not low hanging fruit.
It's a marketing problem, they market the code you accept as efficiency. If they would also add the 97% of the code you have to remove carefully again it wouldn't be that a nice metric. I believe we need to adapt the plugins on our own or write a plugin watchdog, something that monitors completions, immediately removes them and offers a word-by-word insert of the code.
A use case from He wants to accept the first couple of words here (but not the entire completion): ! ... ~~ A use case for line based acceptance: !
For jetbrains IDE's you can use my plugin () You press CTRL+ALT+D and it will complete the sentence word by word. So in your example you press it 3 times (you'll be after "to", then you type "have a per" and you can continue with the shortcut 3 more times on the new completion text. Or just "TAB" if all is good after your intervention, it doesn't block you from using the default behavior of copilot Though the plugin only works on IntelliJ IDE's (you need to install 'LivePlugin' and 'Stewardess')
I love this suggestion. I encounter the scenario of wanting to only accept a suggestion partially a lot.
would you prefer word-by-word partial acceptance or line-by-line?
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This is essentially a more general issue of the closed Markdown styling support are missing in the following, missing bold and italic: Solarized Light Red Abyss Solarized Dark Tomrrow Night Blue See screenshot below for an example. For High Contrast, section heading () are not in bold. I am unclear if it's a bug or intentional. Screenshot for Solarized Dark !
Hi, I tried bold and italic with these themes: theme-tomorrow-night-blue theme-solarized-dark theme-solarized-light theme-red theme-kimbie-dark theme-abyss hcblackdefaults(High Contrast)
Issue Type: <bBug</bRelated to and Steps to reproduce: and or corresponding JS settings. Create new TS or JS file and paste next code: and ! TS Version 4.4.0-dev. VS Code version: Code - Insiders 1.59.0-insider (, 2021-07-28T05:13:47.114Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/assign
/ Can you please take a look? I believe that folding generates two new requests for inlay hints that VS Code then displays incorrectly. Here's the TS server trace from folding with only : The position of the hints seem correct to me. I don't know why VS Code requests the hints twice here though (or why it needs to re-request any hints on folding in this case since no new code became visible)
These are the visible ranges: ! And vscode sends two requests, one for each range. For some reason, each reuqest returns one inlay hint, so in total, there are 2 inlay hints: ! do you have an idea why this is? To me, it looks like a bug in the provider, there should not be a result for the second request.
Emmmmmm... I think I know the reason. In the tsserver. For each request, we will get the hint in the area that overlay with the visible range (not strictly included). Honestly, I don't know about this behavior. We may could de-duplicate these items?
Can't you just filter out all inlay hints whose position is not in the requested range?
Well, do you prefer to do it in vscode or ts side?
Hmm, maybe actually in vscode.
Verified fixed with TypeScript Nightly in
Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!
Type: <bBug</bHi, My name is Ebrima Mbye. I have been using this wonderful IDE for some while now. However, recently I have noticed that when I run a program, the output in the terminal window does also include the memory location of the file or folder I am working on. Sample output: "93c9--e1dddca87b23PS C:UsersUserDesktopNewEbrimaProgram" This is not a super cotly problem, but I just wanted to bring your attention to it. Thank you for your valuable time, User, Ebrima Mbye, Java programmer. VS Code version: Code 1.88.0 (, 2024-04-03T13:26:18.741Z) OS version: WindowsNT x64 10.0.
Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (44)</summaryExtensionVersion ------ codesnap1.3.4 vscode-javascript-snippet-pack0.1.6 vscode-django1.15.0 githistory0.6.20 python-environment-manager1.2.4 python-extension-pack1.7.0 code-runner0.12.2 vsc-python-indent1.18.0 kodezi2.2.2 debugpy2024.4.0 python2024.4.0 vscode-pylance2024.4.1 jupyter2024.3.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.9 vscode-jupyter-slideshow0.1.6 cmake-tools1.17.17 cpptools1.19.9 cpptools-extension-pack1.3.0 vsliveshare1.0.5918 sqltools0.28.1 sqltools-driver-mysql0.6.0 autodocstring0.6.1 vscode-python-typehint1.5.1 fabric8-analytics0.9.4 java1.29.0 LiveServer5.7.9 pythonpack0.3.0 javafx-support0.0.1 tabnine-vscode3.86.0 open-in-browser2.0.0 bootstrap4-vscode6.1.0 cmake0.0.17 intellicode-api-usage-examples0.2.8 vscodeintellicode1.3.1 vscode-java-debug0.57.0 vscode-java-dependency0.23.6 vscode-java-pack0.26.0 vscode-java-test0.41.0 vscode-maven0.44.0 jinja0.0.8 JavaScriptSnippets1.8.0 grammarly0.24.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.88.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
How may I upgrde?
I meet this problem too.
Today when I use python debugger to debug python files, something wrong happen in vscode 'Python Debug Console'. Output reads: ncher' '7541' '--' 'D:' ;-402f-491b-bdb5-ee7fdd8b6e0cncher' '7541' '--' 'D:' ;-402f-491b-bdb5-ee7fdd8b6e0cPS D:I have neven seen strange characters before. This string wants to overwrite what I want to print in python file and still appear with empty python file. ! My VSCode version is 1.88.1. Hope Greatest Microsoft Engineers will solve this problem. Thank you very much~ PS: To exclude influence of other entensions,I only use this four extensions. !
I've been having a very similar issue for the last week or so. I'm running Windows Powershell (5.1) in an integrated terminal in VS Code on Windows 10. If I run a command that wraps over to the second line of the terminal, an unfamiliar GUID along with some other characters (see red boxes in screenshot below) appears interspliced with the text of the command I just ran. Makes a little difficult to use the terminal. PS I don't encounter the same issue when running the same command windows powershell 5.1 directly (ie not as an integrated terminal in VS Code) ! VS Code version info: Version: 1.88.1 (user setup) Commit: Date: 2024-04-10T17:41:02.734Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. Powershell version info: ! Windows verison info: ! Installed extensions (both disabled -- enabling or disabling has no effect on the issue) !
Thanks for the issue, what happens if you comment out your file?
same thing happens with user commented out. !
I believe that's just your current working directory, which reflects the folder you're in. This is working as designed. You can change the behavior by tweaking your setting.
Unfortunately, it seems unchanged when set the value of as ${fileDirname}. And when clicking Run, it looks like to execute a to stop something runnning. Truthly, I would accept this strange long string in my sonsole but it wants to overwrite what has been output. So, if want to print some message in console without owerwritten, I need to add this code above the whole codes.
What if you set it to something else? Like workspace folder?
I've tried setting [] to other value with different directory and drive letters. But it only changes the initial working directory in Teriminal <pwsh, not in Integrated Terminal <Python Debug Console. Also I manually changed <Python Debug Consoleworking dir, it looks like the same problem. So it has no positive influence on this problem.
Who closed this? Why close it when the problem is not yet solved? On Tue, Apr 16, 2024, 1:53 AM Megan Rogge
does this reproduce if you disable all installed extensions?
updating my "" value in the user settings json did not resolve the issue. As I mentioned before, all installed extensions are already disabled and the issue still occurs.
I think this is the shell integration set command line nonce being passed echoed instead of being passed in with the sequence. I see 2 versions of Windows mentioned and both are Windows 10 so this makes sense here. I'm thinking we'll just not verify the command line via the nonce for conpty under Windows 10.
Are there verification steps for this?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Running any command in Windows PowerShell (v5) is the verification steps
I'm unable to repro the issue in Stable on Windows 11.
I can't even reproduce the original issue on my Windows 10 VM at home with VS Code 1.88.1. has the issue been fixed for you in the latest VS Code Insiders? You can get a copy at
Thanks for your reply.