Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

thought that was the behavior today? Just opened the Command Palette... focus is in the input: <img width="830" alt="image" src="https://user-"
I mean when you run a command that opens a quick pick such as !
commenting out this code fixes it
so I think we need to check there if and not focus
Looks like this use to be reported in
! odd I don't repro with that command you have... wonder if we have a conflicting setting. Also VoiceOver did read out the placeholder in this case.
for me, the placeholder is not read in most cases (but it is with the changes in the PR)
my repro steps were when in a multi root repo, run that command. the first quick pick placeholder isn't read
Hi and I see this as moved to the backlog. Do we have a rough date in which this could possibly be looked at again? I plan on telling the testers that you two are looking at the bug. Thanks!
I did it in "holiday mode" as a lot of us are disappearing for the holidays. I'll leave it on January
Thanks for the update that totally makes sense. I will let the testers know. Happy holidays!
do you see a way to do this? it's not clear to me where the item is getting focused
is open to testing the PR once it is available
We'll try to fix this in February with the following read by the screen reader via : placeholder of input box (note this doesn’t logically have to be the placeholder, it could be an aria label set somewhere) number of items in the list the label of the highlighted item in the list (aka the first item in the list)
I just discussed with and he says "I need an ARIA expert because I can’t get this to work nicely. is what we use today on the quick pick input box. That points to the focused item in the list. This is needed because true focus always stays in the input box. The problem is that if an element has AND the is ignored. I’ve tried a few other solutions and haven’t had luck, unfortunately. Looking for creative solutions" might you have suggestions here?


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Just to provide an update... After chewing on the problem yesterday, my best idea is to try to mirror this design pattern as much as possible: Applying it to the quick pick means making the following changes: in a11y mode, we do not focus any of the items in the list. Doing this, we can easily ensure that the placeholder is read out because aria-activedecentant won’t be set yet in a11y mode, When the user types something in the input box, aria-activedecendent is removed and we remove the "active" state of the elements (thus focus goes back to the input) When pressing down the first element is highlighted. aria-activedecendent is set on the inputbox pointing to that item. The item gets read out. Nothing new here. While this pattern is fine, it's not really what I want because the QuickPick isn't really a combo box (though I'll admit it's close). I’m sad because I would rather not have specific a11y mode behavior here… but this is the best I think we can offer with my ARIA skills. Tl;dr: I need a solution for reading the placeholder of the quickpick input box first and then read out the first highlighted item in the list (the aria-activedecendent)
Hi team. I’m reading the thread and I’m probably missing something but I’m concerned that there is perhaps a misunderstanding about how the quick input experience works in general and the particular issue of the Bridge to Kubernetes extension. Perhaps I’m missing the problem, but the quick input list works well for me. Here is an example: the command palette by pressing CTRL +Shift +P a. NVDA announces the label and placeholder text for the editable field as follows: “Type the name of a command to run. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel”. type git, for example, and select the Git clone command with the arrow keys and Enter. a. Upon selecting the command, focus returns to the editable section and NVDA reads the prompt as follows: “Provide repository URL or pick a repository source. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Provide repository URL or pick a repository source. blank”.


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

use the arrow keys to select the option to clone from remote sources and press enter on it. a. Upon pressing Enter, focus returns again to the editable field and the prompt is read again: “Repository name (type to search) combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Repository name (type to search) blank”. I wouldn’t expect this to behave any different. The only instance where I have observed a different behavior is with the Bridge to Kubernetes extension where, upon selecting the connect command, for example, screen reader focus seems to jump directly to the list instead of the editable portion which is the standard behavior, maybe because aria-activedescendant is set at a time when it shouldn't? why you would like the placeholder text and the first highlighted item to be read together? I understand the placeholder text as the label for the editable field, therefore it is relevant only when the editable field is focused. By focused in this context I mean that it has screen reader focus, not keyboard focus. When we manipulate aria-activedescendant we are communicating the screen reader to focus on a different control, therefore the label of the control with focus shouldn't be read. The label of the list portion is "Quick Input list", and that is actually the hint that we are now exploring the list of options. I fully agree that we should stay away from an A11Y exclusive mode as much as possible.
because this is the behavior of a sighted users today. They are able to see the placeholder in the input box and the first item in the list is already focused (using ). This allows a user to be shown the quick pick and be able to hit to accept the first item in the list. Putting the "quick" in "quick pick". Today, users of a11y mode via the setting have a different experience, which is what you describe... no item is initially focused and a user in a11y mode must hit down arrow to get to the first item in the list.


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

My wish is that we could have the same experience for users of a11y mode and not... but my research above, albeit not expert level, has given me the perspective that it's just not possible... and that it would be easier to fix the bug you call out which can be simplified to: "When we chain quick picks we need to remove on any item if one exists so that the 2nd quick pick reads the placeholder"
Thanks I think I understand now. Since this is really not a combobox, I would then suggest a change to the way this works from a keyboard and screen reader perspective. Please take this as a general idea which could be significantly refined or completely abandoned. and Shift +tab can be used to move focus between the edit field and the list box. Tab works now, but shift +tab doesn't return focus to the text field. Visual keyboard users can press Enter in the text field to trigger the first element in the list which is selected. Blind screen reader users can tab to the list to hear / read the element selected and press enter from there. text in the text field changes selection visually and updates an aria-live region with the selected item in the list. In a way it is better than manipulating aria-activedescendant because the text is still editable. note: It should be a visually hidden live-region which will only contain the visually highlighted item at a given time. while focus is in the list filters the list as it does now but doesn't update the aria-live region because screen readers are tracking ffocus in the list itself therefore there is no need to announce anything. focus is in the text field, pressing down arrow changes selection in the list and moves focus to the list itself. quick pick changes resulting from selecting an option, we reset focus to the edit field so that the placeholder is read. Screen reader users can then tab to the list to hear the selected item / navigate, or start typing in the edit field. remove the combobox role from the text field because we agree it is not a combobox. note: As a blind screen reader user myself, I don't know how the experience looks / feels like from a visual perspective.


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

For example, I don't know if sighted keyboard users can edit the text as they type, or if there still an insertion point visible in the text field as ones navigates in the list with the keyboard as it is now.
I think we are on to something here... Thanks for your input. It sounds like, from what I can tell, you are suggesting we drop aria-activedescendant usage from the input box and go with your alternative. I'm intrigued by this idea. I have a couple of follow ups mostly because my ARIA skills are quite low: you: Could you explain the difference between these two approaches? How are they represented differently via a screen reader? Just to confirm, yes, the inputbox that currently has is still editable and should be editable. We want users to be able to continue typing to further filter the list... just like a combobox. said: Today, when you type a character, the active item in the list becomes the first item in the list. I would imagine we would still announce via if that item isn't the one the screen reader user is on? clarify what you said here: Yes. Visual users are able to see a cursor in the input box that they can move left to right as they choose and edit the text in the box while an item in the list is active (again, similar to the combobox example I linked above). This works today because true focus is entirely kept by the input box. "fake focus" or what we call "the active list item" never actually gets browser focus, it just appears "focused" or "active" or "highlighted" to the user compared to the items in the list.
Hi ! quoting you: Aria-activedescendant overrides DOM focus. It means that, as soon as we add the property, screen reader focus goes to the list and screen reader no longer track the cursor in the text field. If we use an aria-live region however, changes in selection can be announced while focus is maintained in the input field for the user to edit. In this way if an element is selected in the list by default, we can announce that element and the placeholder text will be read by the screen reader due to the focus event. We may not be able to fully control the order in which both events are read, but that's a lesser problem in my opinion.


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Does it make sense? Yes, that is correct. actually, your visual explanation has helped me understand the entire experience better. I initially thought that there was no cursor in the text field at all while the user was typing.
thanks a lot for your comments! I really want to sit down and play with aria-live some more based on your idea. Considering that this issue is pressing, I've made a small change to get the placeholder to be read out.
happy to test that change when it becomes available in an insiders build, or remotely with you in case you want earlier testing. for my idea to work, it would require some changes in keyboard behavior as well, and careful testing so that we don't break current user expectations around a widget which is critical for some customers. feel free to reach out if you need additional input.
<!-- 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!
I did some testing using the latest insiders build and NVDA Results with screen reader mode on: Placeholder text is announced when the widget receives focus. When typing in the text field, the number of results is announced by NVDA but not the highlighted option. This can be a productivity killer. I believe the announcement of the highlighted option is the most important piece of information while typing. the number of results is irrelevant at this point. It becomes important when the user starts to navigate with the arrow keys, and at that time the screen reader takes care of it. Screen reader mode off: When the widget receives focus, the number of results is communicated by NVDA followed by the announcement of the quick input list and the highlighted element, but the placeholder text is not announced, likely because the "combobox" portion doesn't have focus. when typing, NVDA announces changes in the highlighted option in Braille and speech as expected.


Question: private _sortByLabel = true; private _autoFocusOnList = true; private _keepScrollPosition = false; <del> private _itemActivation = this.ui.isScreenReaderOptimized() ? ItemActivation.NONE /* https://github.com/microsoft/vscode/issues/57501 */ : ItemActivation.FIRST; </del> <ins> private _itemActivation = ItemActivation.FIRST; </ins> private _activeItems: T[] = []; private activeItemsUpdated = false; private activeItemsToConfirm: T[] | null = [];

Version: 1.77.0-insider (user setup) Commit: Date: 2023-03-23T10:21:45.873Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
Closed Verified the issue in latest environment: Version: 1.78.0-insider (user setup) Issue is fixed. Hence closing the bug. please find attachment for reference. https://user-


Question: this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

Type: <bBug</bthe settings like below: : new terminal via ctrl+` from terminal input. Pressing Shift+Tab moves to the terminal buffer. Shift+Tab should be passed to terminal as an input key. The focus needs to remain in the terminal input field. We need when cycling back through shell auto-suggestion or ipython completion. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-19T05:34:51.441Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (90)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.1.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 dscodegpt2.1.14 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.12 copilot1.97.271 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11.


Question: this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

python2023.12.0 vscode-pylance2023.7.30 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.301.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.1717 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5873 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.2 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.20.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.23 latex-utilities0.4.10 chatgpt1.1.2 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
related this also reproduces in stable VS code
We're going to remove the keybinding altogether as it should enter the buffer when toggle tab moves focus is enabled and not (as designed) without that
Changing the keybinding could throw users off,


Question: this.element.ariaRoleDescription = localize('terminal.integrated.accessibleBuffer', 'Terminal buffer'); _instance.onDidRequestFocus(() => this.hide(true)); this.updateEditor(); <del> this.add(this.editorWidget.onDidFocusEditorText(async () => { if (this.element.classList.contains(ClassName.Active)) { // the user has focused the editor via mouse or // Go to Command was run so we've already updated the editor return; } // if the editor is focused via tab, we need to update the model // and show it this.registerListeners(); await this.updateEditor(); this.element.classList.add(ClassName.Active); })); </del> // xterm's initial layout call has already happened this.layout(); }

though is wondering if we can treat this like a widget with results/ input and allow moving between the two with keybindings consistent with
Shift+tab is still going to the workbench even when I remove that keybinding and have tab moves focus mode off
We now allow using or to go to the terminal accessible buffer instead. I think it makes sense to remove as a keybinding next iteration if we agree that makes sense and The only downside of that would be users might already have in their muscle memory.
If we cannot resolve the synchronization issue with autocomplete and shift +Tab, I am in favor of removing the key-binding. there are worse things than retraining mussel memory.
Yes, and I just discussed, and we agree it can be removed this iteration.
We will also remove the tab index
I cannot reproduce the original issue in stable (either 1.81 or 1.78). What are the steps to verify?
Sorry, to verify, focus a terminal with screen reader mode enabled. Use . the accessible buffer should not open.
This does input and no longer shows the a11y buffer, but the event also bubbles beyond and moves the focus to the panel title incorrectly: !
Guessing we need to do something with tabindex that must've been removed in order to get this to work
I think it would be either shift+tab needs to be specially handled in or we should handle it and cancel the event in the custom key event handler.
not sure how this was working before. I dug through commits and tried reverting this one, which didn't help.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

I love VS Code, But please, don't make that option default : mirrorCursorOnMatchingTag it's a nightmare Thank's
can you please share more detail about what behavior makes it so bad for you that you had to change the setting?
/needsMoreInfo
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our guidelines. Please take the time to review these and update the issue. Happy Coding!
Hey I agree with with this one here. I first came across this new feature today after updating VSCode, and after some searching, saw the setting & feature mentioned over at IMHO - This should be disabled because it feels unnatural to select an HTML tag after it's initially created and want my IDE to automatically create multiple cursors on it's closing tag by default. I'm more likely to go to an opening tag and add attributes (or like when I'm working on an Angular/React project, add directives, inputs and outputs to my components) than want to have multi-cursors to rename the component/tags (which if needed, can be done with the Ctrl+D key binding anyway). Took a few minutes of head scratching to figure this all out, and seems like I'm not alone on this one. I'd say it's one of those things that could be enabled if needed, but disabled by default. :)
I might have a narrow use case here but I use to write Angular code. These multi-cursors on HTML tags completely ruined my ability to edit the file. I tried copying the current line with and it copied both the line where my cursor was and the line with the matching HTML tag. I didn't notice this until I tried pasting with and it pasted both the line I copied and the line with the matching tag a couple lines above that. I noticed it changed more of the file than I intended but it took me multiple operations before I realized multi-cursors were the culprit. I tried using to open a line below my current line and it two lines because there were two cursors. Then I tried using to append to the end of a line (after an HTML tag) and it appended only on the first cursor (the opening tag), which meant I couldn't append to the end of the line. Thank you for adding the setting because this was infuriating to me.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

I couldn't understand how my vim plugin was so horribly broken. I could probably complain to the vsvim project that they should disable this setting when installing the extension but I figured I might as well throw my use case into this issue first.
Instead of mirror cursor on matching tag (which conflicts with vsvim for me), have some feature which only changes the matching tag name. I don't want to add to the closing div tag (as it just happened to me). Also when using vsvim, and you press to open a new line, it opens a new line in both locations.
While I like the idea of being able to edit start/end tags at the same time, the way mirrorCursorOnMatchingTag works currently has some flaws that are really easy to trip over. I noticed it has special handling for typing a space in the start tag which is nice, but there are some other cases that can cause problems. For example, pasting - currently if I try pasting an attribute into a bare start tag, my end tag gets the attributes too, which I don't want and have been frustrated by a number of times. There's also an issue with getting double comments when toggling comments for a tag that starts and ends on the same line. A third issue is that it doesn't seem to work when making a selection with the mouse (either by double clicking the start tag or by dragging a selection in the start tag), which is my primary way to rename tags. Suffice to say, my initial impression is that this feature is buggy and doesn't completely accomplish what it was meant to do, and so I don't think it should be a default option until it can work more smoothly and not cause disruptions to my regular editing.
I just wanted to change the closing tag of a specific element. Since this feature enabled itself after the last update unawares to me, I could not change the tag because the feature also changed the opening tag that element, and also other identical strings in the file. I had to google myself silly just to turn it off. Then, when I tried to turn it back on to test it, it didn't work at all. I don't see any productivity benefit with this feature, at least not in the current unreliable state. The use cases where I'd want to turn if off far outweigh the productivity benefit that I might glean from having it on by default.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

It's irresponsible to introduce and enable a new feature by default. I wasn't pleasantly surprised at all.
As mentioned in some comments above, I don't mind the feature but the fact that there are two cursors simply because the cursor is inside and next to the tag name is a bit weird in my opinion. I mostly work using Angular and it's a bit frustrating when code is pasted in the opening tag and gets pasted in the closing tag too. Why not make the feature that the double cursor appears when any text of the tag name is selected (i.e. highlighted)? If I explicitly want to change the tag name I would then simply double click tag name name type therefore changing the opening and closing tag. ! If for some reason I select part of the opening tag name, the closing tag name gets selected too (and vice-versa). !
As we were in the comments, it is wonderful that VS Code allows a plugin mechanism so that I can have extensions that make all sorts of nifty things happen when I edit, such as adding matching tags, inserting tags from abbreviations, or whatever. That's what extensions are for. But the VS Code made two big mistakes here. First they turned on a a feature automatically that should be an extension. It fundamentally changes how the editor operates. I make some changes here, and I don't expect, without some further action on my part, that it will at the same time make changes over there. I see flashing cursors everywhere while I'm trying to edit it, and things I did not touch suddenly get modified. An editor is not for surprises, especially when it comes to modifying content. It was bad enough turning this thing on by default, but the other horrendous mistake was pushing out this half-baked, ill tested feature on us. It has huge bugs, which have been reported already by many—see for example . If I have an element that has attributes, when I select and delete the attributes this new buggy feature selects and deletes content outside the closing tag, completely corrupting content; removing essential, unrelated content; breaking the document; and losing the information. VS Code is becoming my go-to editor, and it is becoming beloved by a huge community. Don't squander this support by starting forcing half-baked and ill-tested gadgets on us.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

There are thousands of gadgets we can turn on with extensions, and it's awesome that such a facility is available for us. At the least, the very least, this should have been tested and re-tested for six or nine months, made available in an extension or an option, and then if there was an outpouring of requests perhaps a dialog that pops up after an update that says, "hey, you should really turn this on". If all goes well, and still no problems, you could turn it on for new installs. But instead you threw something together half-baked and forced it on existing installations! Are you starting to see how it this interesting idea was executed all wrong? Look, if you have all these extra coding cycles and want to implement something cool, why not go which is one of the huge remaining bugs that mar an otherwise fabulous editor. Congratulations on the editor in general, and good luck learning from this lesson and making it even better.
Since you can use Rename Symbol (F2 by default) on HTML tags, I think having automatic double cursors is unnecessary. In my experience, renaming HTML tags does not happen often enough to warrant the automatic double cursors - since I am already used to renaming symbols with F2, it's more intuitive to do it that way.
you the needsMoreInfo tag to this issue. Is there sufficient info now or is there something else you're still waiting on? ? Anything else you need?
We can consider disabling it by default, but that means this feature won't be discoverable at all. Some issues are hard to fix, others are impossible. We are working on an improvement. You can find more details in . This feature does what it says: Creating another cursor when you are on an open/close tag. Some actions, when two cursors are present, perform differently than one cursor. Like, if you press Enter when two cursors are there, it produces two newlines. We can't bend multi-cursor to work differently, just so when you press Enter it only creates one newline. I'm not sure how you can use VSVim in VS Code (isn't it only for Visual Studio)? During my testing it had some issues with VSCodeVim, because of the way VSCodeVim is implemented. But most of the time it works fine.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

In short: we'll use this iteration to find workaround for some of the issues. If there's no easy workaround, we might take a more general approach in , and meanwhile disable this feature by default. If you have issues with concrete reproducible cases, please open new issues.
So you're saying then that this will be Microsoft's policy moving forward, that is, to make new and unpopular features enabled by default in order to make them 'discoverable', so that users then have to sacrifice their time and productivity with vetting processes like this? It would seem that it would be in the user's best interest to let users discover new features in the release notes and let those who wish to test the feature do so on their own time, rather than forcing new features on the general userbase who actually depend on reliable editors to meet deadlines and earn their daily bread. Thanks for informing us of this policy now so that users can let it inform their choice of editor in the future.
I can't dictate Microsoft policy. Please don't make extreme straw man statement to criticize it. We'll consider disabling it by default. That's why the issue is open and marked with .
Yep, sorry, I meant , totally messed up there. :manfacepalming: I think the issue here is that by enabling the feature by default, I had no idea what the feature "said" or that it even existed. All I knew was that multiple cursors kept popping up when my cursor was on an HTML tag. Yes, precisely. That's the problem. Some actions performed differently and I didn't know why. Nobody is asking for the multi-cursor feature to behave differently, we're saying that only the users who want_ multi-cursors should deal with those nuances. This GitHub issue is full of comments from people who were confused/frustrated by the change in default behavior, which is arguing for it to be disabled by default. I'm curious, what is the argument for enabling the feature by default? Is that discussion documented somewhere? I'd like to see why the feature was considered so useful as to warrant being enabled by default because as far as I can tell, the only benefit is in the case where you need to rename an HTML tag. And I agree with comment: Is there another use case that I'm missing?


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

With all due respect, it should be obvious that it's the decision to enable it by default that most people in this thread are objecting to. That's either a one-off decision that was made for this particular feature or it's a policy decision that will be made for other new features moving forward. I apologize if my comment came off wrong - Code is a great editor. What I'm saying is that I hope this is just a one-off, because if it were to become the default method of launching new features, it might affect users' willingness to use Code or to upgrade for fear of encountering unwanted new features that result in loss of productivity.
as noted, I run into this multiple times a day working in Angular. I had thought it was an extension gone rouge, as it seemed like a feature that an extension would add. So I spent my morning disabling them one by one, until I opted to search and see if this was a new vscode "feature" . For what it's worth, I also disagree with the notion that new features should be enabled by default to encourage "discovery". That's what the update and changelogs are for. If I was a new VSCode user coming in post-update and I ran into this not knowing it was a "feature", it would turn me off from the editor completely. It's not what I would consider typical behavior for what an editor should do, but that's just my two cents.
I specifically looked to find this issue/topic as I've been hit by it multiple times during a day of coding now and it did introduce bugs in my code. The worst case is when I reorganize HTML code and sometimes have to delete or edit the starting tag. Then the closing tag can get deleted too, but nothing is of course re- if I start typing in the new/changed starting tag because it has now no ending tag counterpart. Well, maybe it's immediately after my new starting tag, in the completely wrong place. This can introduce hard to immediately discover bugs in my HTML because of sometimes deep nesting in long blocks of code and removed or messed up closing tags (I've particularly discovered things like suddenly missing end brackets that I've only noticed early on thanks to syntax highlighting?).


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

It's especially frustrating because sometimes things happen and other times it doesn't seem to, and I have a hard time mentally getting around when and why it's doing things, so I end up having to baby sit the editor. I think that for me, it would be easier to have more predictable behavior back again. I'm very used to renaming both tags, no problem there. But sure, at least now I know what the setting is. I'm just offering this as feedback on "how does this impact me negatively".
This feature is a poor substitute for real code refactoring, and should never have been enabled by default (IMO it should never have been to the main application at all). If you were worried that users would not discover the feature, you could have a hint about it in the changelog. Or better yet; you could have made it as an extension, and advertised it in the extensions panel. Multiple cursors are really handy in certain scenarios, but it is vital that the user is fully aware and in control of where they are. One really essential problem with this feature is detecting when the user is actually modifying the tag name, and not just adjacent code. Another is that there are other ways of modifying the tag name than just adding or removing characters. I do not believe that these issues can be solved without proper code awareness, and if the editor has that then this feature is redundant anyway. Given this code example... ...I have three examples of how this feature breaks the code while I am editing: want to remove the extra whitespace preceding the class-attribute, so I place the cursor at the end of the tag name and hit <kbddel</kbd. Code is now broken because the end-tag has no closing angle bracket (). inadvertently typed in the attribute "component" without a space after the tag name "custom-angular", and I fix it quickly by placing the cursor between the two and hit <kbdspace</kbd. Code is now broken because the end-tag does not match the start-tag. want to remove the prefix "custom-" and I do so by placing the cursor at the end of the prefix and hitting <kbd<- Backspace</kbdrepeatedly.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

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.


Question: "html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

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


Question: return; } <del> await ensurePublished(gitRepo, uri); </del> <ins> if (shouldEnsurePublished) { await ensurePublished(gitRepo, uri); } </ins> let repo: { owner: string; repo: string } | undefined; gitRepo.state.remotes.find(remote => {

Testing Steps: Open locally cloned vscode repo with any branch Welcome page Connect to... Continue Working in Nothing happens after this for me... but I do see the commands get run:


Question: id: ShowCurrentReleaseNotesActionId, title: { value: localize('showReleaseNotes', "Show Release Notes"), <del> mnemonicTitle: localize('mshowReleaseNotes', "Show &&Release Notes"), </del> <ins> mnemonicTitle: localize({ key: 'mshowReleaseNotes', comment: ['&& denotes a mnemonic'] }, "Show &&Release Notes"), </ins> original: 'Show Release Notes' }, category: { value: product.nameShort, original: product.nameShort },

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?


Question: return; } <del> await result.repository.applyStash(result.stash.index); </del> await commands.executeCommand('workbench.action.closeActiveEditor'); <ins> await result.repository.applyStash(result.stash.index); </ins> } @command('git.stashDrop', { repository: true })

a new file with the following content and commit it. the file to like as follows, save it, and create a stash with it the file to like as follows, and save it the "Git: View Stash..." command and pick the created stash diff in the stash should look as follows: <img width="921" alt="image" src=""


Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { Registry } from 'vs/platform/registry/common/platform'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions } from 'vs/platform/configuration/common/configurationRegistry'; suite('ConfigurationRegistry', () => { const configurationRegistry = Registry.as<IConfigurationRegistry>(ConfigurationExtensions.Configuration); test('configuration override', async () => { configurationRegistry.registerConfiguration({ 'id': '_test_default', 'type': 'object', 'properties': { 'config': { 'type': 'object', } } }); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['config'].default, { a: 1, b: 2 }); assert.deepEqual(configurationRegistry.getConfigurationProperties()['[lang]'].default, { a: 2, c: 3 }); }); test('configuration override defaults - merges defaults', async () => { configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['[lang]'].default, { a: 2, b: 2, c: 3 }); }); test('configuration defaults - overrides defaults', async () => { configurationRegistry.registerConfiguration({ 'id': '_test_default', 'type': 'object', 'properties': { 'config': { 'type': 'object', } } }); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['config'].default, { a: 2, c: 3 }); }); }); </ins>

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.


Question: @IFileService private readonly fileService: IFileService ) { super(lifecycleMainService, configurationService, environmentService, requestService, logService); <ins> } initialize(): void { super.initialize(); </ins> if (getUpdateType() === UpdateType.Setup) { /* __GDPR__

run you'll notice that in the main process before creating the renderer the update service takes its time (~5-10ms). while that's not much it seems unnecessary and "block" the renderer for no good reason <img width="1101" alt="Screenshot 2020-01-31 at 14 45 07" src="https://user-"
This is only problematic in macOS where calls into the native which blocks.
Thanks


Question: @ITextFileService private readonly textFileService: ITextFileService, @IExplorerService private readonly explorerService: IExplorerService, @IUriIdentityService private readonly uriIdentityService: IUriIdentityService, <del> @IPathService private readonly pathService: IPathService </del> <ins> @IPathService private readonly pathService: IPathService, @IConfigurationService private readonly configurationService: IConfigurationService </ins> ) { super(TextFileEditor.ID, telemetryService, instantiationService, storageService, textResourceConfigurationService, themeService, editorService, editorGroupService);

We don't want to officially have the hex editor be recommended for non-textual files, but what about a setting like that can be used to open a binary file in a given editor instead of showing the "binary file" message? ! I would love it if I could have all non-text files automatically opened in the hex editor.
To verify ensure the setting works as expected. Setting it to a custom editor should automatically have that editor be opened when a file is detected as binary.


Question: for (const defaultConfiguration of defaultConfigurations) { for (const key in defaultConfiguration) { properties.push(key); <del> this.defaultValues[key] = defaultConfiguration[key]; </del> if (OVERRIDE_PROPERTY_PATTERN.test(key)) { <ins> this.defaultValues[key] = { ...(this.defaultValues[key] || {}), ...defaultConfiguration[key] }; </ins> const property: IConfigurationPropertySchema = { type: 'object', default: this.defaultValues[key],


Question: type: string - name: VSCODE_BUILD_MACOS type: boolean <ins> default: false </ins> - name: VSCODE_BUILD_MACOS_ARM64 type: boolean <ins> default: false </ins> - name: channel type: string default: stable

The stage is now a bottleneck to having the platform specific stages run: ! Each job compiles each target serially. We could further parallelize all targets across different jobs. !


Question: return; } <del> const root = element instanceof SearchResult ? null : element; this.tree.setChildren(root, this.createIterator(element, collapseResults)); </del> <ins> if (element instanceof SearchResult) { this.tree.setChildren(null, this.createIterator(element, collapseResults)); } else { this.tree.setChildren(element, this.createIterator(element, collapseResults)); this.tree.rerender(element); } </ins> }); } }

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. !


Question: id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

<!-- 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.


Question: id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

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.


Question: id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

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?


Question: id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

It would be awesome to be able to do both, but if only one of the two is possible, then I would prefer word-by-word.
There is no reason why only one would be doable. A line based completion is a couple of lines of code. Word based completion is half a page if you want to do the word separation smart, or an abstract if it's dumb.
First iteration has been implemented in


Question: { "scope": "markup.heading", "settings": { <ins> "fontStyle": "bold", </ins> "foreground": "#6796e6" } },

<!-- 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)


Question: */ toString(skipEncoding?: boolean): string; toJSON(): UriComponents; <ins> /** * A helper function to revive URIs. * * **Note** that this function should only be used when receiving Uri#toJSON generated data * and that it doesn't do any validation. Use {@link Uri.from} when received "untrusted" * uri components such as command arguments or data from storage. * * @param data The Uri components or Uri to revive. * @returns The revived Uri or undefined or null. */ </ins> static revive(data: UriComponents | Uri): Uri; static revive(data: UriComponents | Uri | undefined): Uri | undefined; static revive(data: UriComponents | Uri | null): Uri | null;

Following test throws: I found this while investigating At that point the editor component is quite broken because of a lot of errors being thrown. Notice how not even a tab shows for the editor: <img width="1058" alt="image" src="https://user-"
that should already throw because at least a scheme is needed. It doesn't because was designed to be the runtime counter part of which never produces such output so some IPC deserialisation cost can be saved.
, that works for me and will also throw when we get bad objects into such as the from
Yeah, my plan is to add an argument like we have in other URI-places. It will default to true and only IPC should be relaxed
Not doing that because it actually already exists as . I believe the adoption/migration task is to use instead of whenever getting uri components from storage or esp from command arguments. Tho, there is one special case for which is that it automatically uses when the scheme is missing. We could make that configurable but a check for might make this obsolete
Closing this after and the ask to use when creating uri from "untrusted" sources
I will see to adopt , I forgot we had it


Question: isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

Type: <bBug</bWhen pressing to collapse all nodes in a list view it leaves selection in such a state that you cannot expand nodes with until you do something to change the selection. ! I believe what's happening is is leaving the originally selected node selected. So after executing the command you end up with 2 selections, your original selection plus the last root node in the list. The original selection is the primary selection, and if it has no children does not have anything to expand and is a no-op. As a user it looks like you have the root node selected, which has children to expand, but pressing does nothing. Pressing then expands the list to reveal your original selection and you see that you unexpectedly have multiple selections. The current behavior of appears to be: Leave the originally selected node selected Add a second selection to the last root node in the list The expected behavior here is: Move selection to the root node of your currently selected node Ideally this also retains multiple selection: each selection is moved to the root node of that selection. VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looking at this again in the File Explorer it looks like the selection highlight is left on the where the original selection was despite the fact that the node is now in a different position. However, the "real" selection is still on the node. This means it looks like one thing is highlighted and pressing opens a different thing.
Just submitted a PR for this. Could you please review it?
What is the behavior supposed to be? Here's what I see: keyboard to focus a tree node that has a parent to collapse all moves to the whole tree and arrow down takes me to the first tree element. Right arrow does nothing.
The current behavior sort-of fixes the issue, insofar as is dodges it by doing something less desirable - moves selection to the whole tree. Imo, selection should remain on the root node(s) of whichever tree branch selection is currently in.


Question: isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

I think this is what the previous behavior was trying to do, it just had an issue with leaving selection in a bad state. A couple examples ([x] denotes current selection): Start state End state, after Stat state End state
I agree, feel free to send an issue for it. Your observations are the fixed state. Here's the entire story: Marking it as verified.


Question: isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

Testing focus on trusted URI list of items tab to navigate to the X to remove an item. Press to trigger removal nicely gets removed from the list, however focus is lost Focus should be preserved in the list on the neighbour item (example: checkout how Explorer does that when deleting a file). I thought this would be tackled via
The trust editor does a lot of full page re-rendering which I should improve (remove) so I doubt this is an issue with the table widget itself.


Question: export async function getInlayHints(model: ITextModel, ranges: Range[], token: CancellationToken): Promise<InlayHintsData[]> { const datas: InlayHintsData[] = []; const providers = InlayHintsProviderRegistry.ordered(model).reverse(); <del> const promises = flatten(providers.map(provider => ranges.map(range => Promise.resolve(provider.provideInlayHints(model, range, token)).then(result => { if (result) { datas.push({ list: result, provider }); } }, err => { onUnexpectedExternalError(err); })))); </del> <ins> const promises = flatten(providers.map(provider => ranges.map(range => { return Promise.resolve(provider.provideInlayHints(model, range, token)).then(result => { const itemsInRange = result?.filter(hint => range.containsPosition(hint.position)); if (itemsInRange?.length) { datas.push({ list: itemsInRange, provider }); } }, err => { onUnexpectedExternalError(err); }); }))); </ins> await Promise.all(promises);

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


Question: box-shadow: none; } <ins> .hc-black .monaco-menu .monaco-action-bar.vertical .action-item { border: 1px solid transparent; /* prevents jumpig behaviour on hover or focus */ } </ins> .hc-black .monaco-menu .monaco-action-bar.vertical .action-item.focused { background: none; border: 1px dotted #f38518;

Refs: Steps: enter high contrast theme hover over menu items they jump up and down while doing that


Question: return this.shouldShowCompositeBar() ? super.getVisiblePaneCompositeIds() : this.acitivityBarPart.getVisiblePaneCompositeIds(); } <del> focusActivityBar(): void { </del> <ins> async focusActivityBar(): Promise<void> { if (this.configurationService.getValue(LayoutSettings.ACTIVITY_BAR_LOCATION) === ActivityBarPosition.HIDDEN) { await this.configurationService.updateValue(LayoutSettings.ACTIVITY_BAR_LOCATION, this.getRememberedActivityBarVisiblePosition()); this.onDidChangeActivityBarLocation(); } </ins> if (this.shouldShowCompositeBar()) { this.focusComositeBar(); } else { if (!this.layoutService.isVisible(Parts.ACTIVITYBAR_PART)) { this.layoutService.setPartHidden(false, Parts.ACTIVITYBAR_PART); } <del> this.acitivityBarPart.focus(); </del> <ins> this.acitivityBarPart.show(true); </ins> } }

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
!


Question: import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; import { IStorageService } from 'vs/platform/storage/common/storage'; import { IThemeService } from 'vs/platform/theme/common/themeService'; <del> import { hasCustomTitlebar } from 'vs/platform/window/common/window'; </del> <ins> import { hasNativeTitlebar } from 'vs/platform/window/common/window'; </ins> import { IEditorGroupView, IEditorPartsView } from 'vs/workbench/browser/parts/editor/editor'; import { EditorPart, IEditorPartUIState } from 'vs/workbench/browser/parts/editor/editorPart'; import { IAuxiliaryTitlebarPart } from 'vs/workbench/browser/parts/titlebar/titlebarPart';

Verification set to enable native title bar in settings open a floating window ensure you see no custom title below the native title


Question: export class ExplorerViewPaneContainer extends ViewPaneContainer { <del> private viewletVisibleContextKey: IContextKey<boolean>; </del> constructor( @IWorkbenchLayoutService layoutService: IWorkbenchLayoutService, @ITelemetryService telemetryService: ITelemetryService,

open explorer select a file press and to copy paste a file in place :bug: nothing happens, in the past I would get a copy of the file
Hmmm. I cannot repro this and am able to copy and paste. Do you have any custom keybindings? What is your setting?
It's the default, this is from the keybindings log
Hmmm I wonder what has happening with your keybindings. Here's mine triggering the explorer specific ones with the proper when clauses. Is your explorer in a non-default position (i.e. not the activity bar)
This gets more and more interesting... The keybinding is there and not (re)configured but it looks like something is wrong with context keys. The seems AWOL. Maybe that's because I moved the explorer around very much last endgame? <img width="2819" alt="Screenshot 2023-03-01 at 16 55 16" src="https://user-"
Think I found the bug. the folders view to the right sidebar the remaining explorer view container in the activity bar Can't copy and past in the explorer anymore
I know this is very early into the next release cycle, but could this be released in a patch to stable VSCode? I have been bitten by this in stable VSCode after the February 2023 update, by dragging Explorer over to the secondary sidebar. Or is there a workaround to restore functioning of these keys, other than resetting the user profile altogether? I've tried dragging the Explorer menu back, and also right-clicking and selecting "Reset Location". Neither seems to "restore" the functionality of these keys. This affects any command using in , such as deleting a file with the Delete key (hopefully people find this issue instead of creating a new one for every such broken key). The workaround I've managed to apply is to manually remove from every expression possible, which may have side effects, but it works in a pinch. Copy all the keybindings below (expand for details, grab bindings between the comments) into your to fix this in a pinch. <details</summary</details
Does the command in the command palette not fix it for you? This will reset all your views to their default positions.
My keybindings workaround bypassed the issue on my home computer yesterday.


Question: export class ExplorerViewPaneContainer extends ViewPaneContainer { <del> private viewletVisibleContextKey: IContextKey<boolean>; </del> constructor( @IWorkbenchLayoutService layoutService: IWorkbenchLayoutService, @ITelemetryService telemetryService: ITelemetryService,

Now I'm at work (both are Windows machines, VSCode up to date), and I went to try your approach. However, I have a lot of menus in my secondary sidebar, so I didn't want to on my main profile, so I did the following: Ensure my workaround from before is commented out Export the profile as Import the profile Switch to that profile Verify that the key doesn't work First, try the less invasive, right-click on Explorer button in secondary sidebar and click key, and others, works again, even when putting the Explorer back in the secondary sidebar Curiously, switching back to the profile, the key, and others, works again, even when putting the Explorer back in the secondary sidebar Never had to go the nuclear option and So, some funny business related to one of the steps above, probably the settings profile shuffle, restored basic functionality of those keys, without having to manually tweak the expressions as before, and without having to go nuclear and . It's possible to work around this with some UI shuffling, but your mileage may vary. My initial request to backport the patch to stable VSCode is not so serious since there are a few workarounds documented here. Also, thanks for the quick work in the PR! I'm looking forward for this behavior to stabilize in future versions, since secondary sidebar Explorer view (without the compromise of moving the whole primary sidebar over) is great!


Question: export class ExplorerViewPaneContainer extends ViewPaneContainer { <del> private viewletVisibleContextKey: IContextKey<boolean>; </del> constructor( @IWorkbenchLayoutService layoutService: IWorkbenchLayoutService, @ITelemetryService telemetryService: ITelemetryService,

mac select an entry in the explorer press to trigger rename the file is being opened, no rename log
tested on windows and this doesn't work for me - not sure if it's necessarily platform specific
Steps to verify explorer that keybindings still work for the explorer
Mac Pro (Intel 2019) user here. I also have the same problem. Before pressing can rename files but now it just navigates to the file editor window.
This will be fixed in the next release which comes out sometime this week. In the meantime -should fix it for you.
Thank you for prompt reply. Yes, it works fine now!!


Question: import URI from 'vs/base/common/uri'; import * as errors from 'vs/base/common/errors'; import { TPromise } from 'vs/base/common/winjs.base'; <ins> import * as arrays from 'vs/base/common/arrays'; </ins> import * as objects from 'vs/base/common/objects'; import * as DOM from 'vs/base/browser/dom'; import { Separator } from 'vs/base/browser/ui/actionbar/actionbar';

Repro Steps: install VS Code native menubar has no keyboard shortcuts Alternative Repro Steps: a keybinding the menubar does not reflect the change.
Must fix.
Reviewed, tested, merged and cherry picked to . See
since you tested this can you please add a verified label


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

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.


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

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.


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

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.


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

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.


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

I am getting the same issue with VS Code Insiders (see atached video file). Version: 1.89.0-insider (user setup) Commit: Date: 2024-04-25T21:21:03.843Z 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.
this was a regression in 1.89, so it was fine in 1.88
can you try again but make sure you recreate the terminal?
Thanks for your continued support on this. I can still reproduce on the latest version of insiders. Version: 1.89.0-insider (user setup) Commit: Date: 2024-04-26T00:56:34.034Z 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.
Sincerely sorry for replying so late on this issue. I donwloaded and installed the latest VS Code Insiders. Unfortunately, this problem still happen. My PC Info is listed below. Commit: Date: 2024-04-26T00:56:34.034Z (1 day ago) Electron: 28.2.8 ElectronBuildld: Chromium: 120.0.6099.291 18.18.2 W8: 12.0.267.19-electron.0 OS: Windows NT x64 10.0. I found something interesting that while you changed the TERMINAL widget size just like maximized the VS Code window or dragged the left side of terminal list, the strange string will disappear. It seems to mean when you resized a terminal window to control how many characters in a line to show on screen, the string which was already output will be changed or even erased. I captured two new videos of this probloem. The first is the origin problem reproduced in the latest Insiders and the second is changing the window can erase this strange string. Hope these useful for solving this problem.
Reopening issue based on feedback above.


Question: $Nonce = $env:VSCODE_NONCE $env:VSCODE_NONCE = $null <ins> $osVersion = [System.Environment]::OSVersion.Version $isWindows10 = $IsWindows10 -and $osVersion.Major -eq 10 -and $osVersion.Minor -eq 0 -and $osVersion.Build -lt 22000 </ins> if ($env:VSCODE_ENV_REPLACE) { $Split = $env:VSCODE_ENV_REPLACE.Split(":") foreach ($Item in $Split) {

i found issue the didnt occur on 1.87 but then could reproduce after upgrading to 1.89. Version: 1.87.1 (user setup) Commit: Date: 2024-03-06T00:21:36.258Z Electron: 27.3.2 ElectronBuildId: Chromium: 118.0.5993.159 18.17.1 V8: 11.8.172.18-electron.0 OS: WindowsNT x64 10.0. Version: 1.89.0 (user setup) Commit: Date: 2024-05-01T02:09:22.859Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: WindowsNT x64 10.0.
it isn't only when paths are long. in insider i'm seeing this with ohmyposh/poshgit in powershell terminal windows, even if i'm at the root of a drive where the path is only a few characters long (though probably related to whatever posh is doing?) ! i'm on win11, insiders 1.90.0
anyway in 1.89, as a workaround i replaced ~AppDataLocalProgramsMicrosoft VS CoderesourcesappoutvsworkbenchcontribterminalbrowsermediashellIntegration.ps1 with the shellIntegration.ps1 from commit and it resolves the issue.
Looks like the only remaining issue with Windows PowerShell (), the fix for that was only just merged yesterday:
- did you have some reliable steps to repro this?
in Windows PowerShell () run a lot command like a few times and ensure a GUID does not show up in the output.


Question: export interface EditSession { version: number; <ins> machine?: string; </ins> folders: Folder[]; }

Testing I'm not sure why I have two entries for edit sessions and wonder if it came from another machine/sessions. It would be great to see some metadata about where the source is coming from, similar to the "Synced Data" view for Settings Sync. <img width="394" alt="CleanShot 2022-07-26 at 10 58 31 src="https://user-"<img width="373" alt="CleanShot 2022-07-26 at 11 00 07 src="https://user-"


Question: return path.split('/').map((segment) => encodeURIComponent(segment)).join('/'); } <del> export async function getLink(gitAPI: GitAPI, useSelection: boolean, hostPrefix?: string, linkType: 'permalink' | 'headlink' = 'permalink', context?: LinkContext, useRange?: boolean): Promise<string | undefined> { </del> <ins> export async function getLink(gitAPI: GitAPI, useSelection: boolean, shouldEnsurePublished: boolean, hostPrefix?: string, linkType: 'permalink' | 'headlink' = 'permalink', context?: LinkContext, useRange?: boolean): Promise<string | undefined> { </ins> hostPrefix = hostPrefix ?? 'https://github.com'; const fileAndPosition = getFileAndPosition(context); if (!fileAndPosition) {

Testing Steps: Open locally cloned vscode repo with any branch Welcome page Connect to... Continue Working in Nothing happens after this for me... but I do see the commands get run:


Question: public readonly inlineCompletionVisible = GhostTextController.inlineSuggestionVisible.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentation = GhostTextController.inlineSuggestionHasIndentation.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentationLessThanTabSize = GhostTextController.inlineSuggestionHasIndentationLessThanTabSize.bindTo(this.contextKeyService); <ins> public readonly inlineSuggestionJustCommitted = GhostTextController.inlineSuggestionJustCommitted.bindTo(this.contextKeyService); </ins> constructor(private readonly contextKeyService: IContextKeyService) { }

<!-- 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.


Question: public readonly inlineCompletionVisible = GhostTextController.inlineSuggestionVisible.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentation = GhostTextController.inlineSuggestionHasIndentation.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentationLessThanTabSize = GhostTextController.inlineSuggestionHasIndentationLessThanTabSize.bindTo(this.contextKeyService); <ins> public readonly inlineSuggestionJustCommitted = GhostTextController.inlineSuggestionJustCommitted.bindTo(this.contextKeyService); </ins> constructor(private readonly contextKeyService: IContextKeyService) { }

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.