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.


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.


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-


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.


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,


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.


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.


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.


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.


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.


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?


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?).


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.


Now if I go back too far, accidentally removing the opening angle bracket (<), and then re-type that character to fix my error, then the code is broken because the end-tag has been converted to a new start-tag. Now all of these are simple examples, and if you are aware of the feature and/or see the errors as they occur, it is super easy to fix the code again. Either manually or by using the undo-feature. But if the code is longer and more complex and the end-tag is out-of-view when the errors occur, it may be quite difficult both to discover the errors and to fix them.
Here is a use case where the default "on" of this new "feature" is incorrect. tl;dr - A proficient vim user can make a horrible mess very quickly with mirror cursor. I rarely use VSCode but at work I need to write up some documentation from time to time and I prefer to do so in html. So I fired up VSCode for the first time in a while and started typing up a doc. I use vim bindings and don't need to look at my editor too much especially when working in the way I was today. So I wasn't paying attention to my editor. About halfway through I opened my work in a browser to review how my old CSS settings were treating the work. It was a garbled mess of half paragraphs and repetition. Using '/', '?' and other regular vim navigators causes multi-cursor insertions EVERYWHERE. Change the default to "off" and test these features against different editing options like Vim and Emacs in the future.
This kind of falls into the same category as any setting that can help users reduce keystrokes (similar to ). When you've built up some muscle memory or expectation for how things behave, and that suddenly changes, it can take time to get used to. Personally I have many of these features disabled because of being used to unconsciously doing many of them manually, and the time investment in changing that and fixing mistakes that occur in-between hasn't seemed worth it. It can be especially frustrating when you are in the middle of something and a feature like this is introduced. Even more so if finding the name of the feature in order to disable it winds up taking more than a trivial amount of time.


The worst part is for those who are uninformed, which is everybody who didn't see the patch notes, the name of this feature would remain elusive until you either find the correct patch notes on stumble upon this thread. How can one disable a feature that has no name? Personally I thought it was a bug with multi-select / multi-cursor that got enabled on accident. Still do actually.
I'm also having issues when moving lines with alt-arrow . I want to move the starting tag higher to include block of code above, but ending tag also gets moved.
I also got hit with this today. I mangaged to edit the opening element but it did not auto select the closing element. When I then tried to edit the closing element it auto-selected the opening element parent to the first one. See picture for example. I also ran into the same issue as and by then my blood was boiling and I literaly screamed from frustration. Features like this should not be activated by default when it clearly messes with peoples personal coding behaviour/styles. !
Had four lines of elements. Selected the opening tags for all four as distinct selections, and then edited to add to each. Didn't realize it was corrupting content in the close tags. Uck. Too dangerous to use, let alone enable by default.
A use case that this feature completely corrupts is reordering HTML tags using the + key binding. It took me ages to realise that when I was refactoring some html, reordering things, why my html was all of a sudden being corrupted because the corresponding tag was being moved as well, and more often than not, incorrectly. This should definitely not be on by default. Thanks for reading.
Created a draft PR, seemed like a pretty trivial change, just need to hear if I have to do any other tests/etc for this
All the complains above explains well, and I just want to add my current brand new face to face experience, which I encountered numerous times and today I finally, "enough is enough"... ! Anyway, thanks for the hard works, to those who work with this feature... but please make it off as default... Thanks...........
I'll turn this off by default and work on , which will be an opt-in feature.
Great, it is nice to hear that it will be turned off by default


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:


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?


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=""


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.


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.


I do not see a duplicate of my issue: ! So I'm in the clear. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.32.0 OS Version: Windows 10 1809 Stable Steps to Reproduce: Visual Studio Code, click on the "Search" sidebar menu item to bring up the huge Search menu. ! for a common word used quite a lot. Like "a", "let", "var", "i", and so forth. the Search displays the total results count, dismiss a few of them. total results count should decrement by 1 per dismissal, or indicate both the original total results count and the remaining non-dismissed total results count side by side when dismissing the search results. For example: ! Does this issue occur when all extensions are disabled?: Yes
For me, it does decrement. You don't see that? You are clicking the 'x' icon on a result row, right?
It doesn't. !
Ok, so I was about to get it to decrement, but that's not done in real-time. ! Both of the GIFs are done in 1.32.1.
That's right, I thought you were talking about the total shown at the top ("x results in y files") in your original post.
This also happens when a new match is or deleted in an existing file match. !


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When using Copilot, users would like to be able to only partially accept suggestion instead of the whole suggestion at once. The users demand either word by word or line by line completion. Desired behaviour: Press a predefined key and accept the whole suggestion. Use a predefined combination of 2 keys to accept the top line of the suggestion. (eg: For a suggestion of 3 lines, the user would need to press the combination 3 times to accept the whole suggestion). The prompt would not show the line already accepted.
this sounds to me like a UX problem. Is there a mock sketch for a potential solution here? Is there some other editor which already supports this? We can also discuss it in one of our UX weekly meetings.
I don’t have a mock sketch. No other editors are supporting this yet but it is a requested features. I wanted to get the discussion going (doing the same for the other editors) to understand the constraints around it as well.
Technically, I think this would be rather easy to implement. I'd love to hear some more UX discussion before we implement this thought. What key-binding do you have in mind?
do you have some UX designers on your team that would like to help here? Once we have some good ux proposal we can bring it in our UX weekly sync on Wednesday to start the discussion.
No I dont have a UX designer in my team. I ll see how i can come up with a suggestion and get back to you
This is similar to Solution for me was 'CMD + -' to accept a word at a time. Something similar here would be great.
Fish shell allows word-by-word completion using the <kbdAlt</kbd+ <kbd&;</kbdkey-combo, which—at least on macOS—is used system-wide for navigating text word-by-word. I notice that I keep trying to automatically use this key-combo, so big +1 from me. ( Did not realise this is the vscode repo.)
awesome idea. since you said this is low hanging maybe we assign to July for the initial investigation? What do you think?
This would be great.


I am loving copilot so far, but this is my biggest UX gripe. Copilot's first suggestions in a new piece of code tend to only be accurate for the first few words. It tends to get much better only after more context is . Not a blocker, but it'd make it much easier to get started.
We did an initial investigation and this is not low hanging as I have initially commented above. Also, this milestone we have been mostly focusing on improving the merge editor. So this one will have to continue in September.
Had a sync with the VS folk and here's some very early thinking: When partial completion is accepted the ghost text should not change - we should use the cache. VS did multiple user studies and users always get shocked when the ghost text changes beneath them Undo is the user gesture to undo the last partial acceptance (this should work out of the box for us). Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as and commands. Open questions (probably not for first version): How to make this keybindings discoverable Should we support the mouse? For example alt + mouse click to accept until the mouse click
I've also previously advocated for a way to accept only a single line out of the multi-line completion. I would strongly support doing this at a line granularity, rather than e.g. token granularity, since I ~never run into the case where I want to accept 'more than 0 tokens but less than a line' of a multi-line completion -- it's ~always either one line or maybe a couple, or the whole completion. Repurposing regular cursor movement commands for partial acceptance when a ghost text completion is open sounds error-prone. I see this kind of key-stealing behavior in some autocomplete systems (especially for ), but it's always optional, since it's really easy to interfere with muscle memory and frustrate people. This would apply to text navigation commands for sure, and it would be even worse in the middle-of-the-line completion case (which would also be wonky if we want an 'accept a single token' shortcut).
Hi! A use case for per-word completion: comment/natural language completion. I want this almost every time that copilot gives me a comment suggestion.


To make sure I understand the shape of the discussion, I think three issues are separable here: 1) whether to offer partial completion; 2) at what granularities (here the use case and example-based analysis is most relevant, and feed back into question 1); 3) if doing it, what default keybindings at these levels to provide so as not to hijack muscle memory (but possibly still utilize it in a parallel modifier key universe)? Is that right, and if so at what stage does the team currently see the conversation? For 3), in Lisp-y language tools, Paredit's keybindings might be a decent template too: in some sense what we are doing here is structurally selecting part of what is an (falling back on a as above) structure before "acceptance" (which is already well-understood as a result of by default keybinding users). That would be a more elaborate form of the partial acceptance, though, requiring a language-sensitive parse, so definitely not low hanging fruit.
It's a marketing problem, they market the code you accept as efficiency. If they would also add the 97% of the code you have to remove carefully again it wouldn't be that a nice metric. I believe we need to adapt the plugins on our own or write a plugin watchdog, something that monitors completions, immediately removes them and offers a word-by-word insert of the code.
A use case from He wants to accept the first couple of words here (but not the entire completion): ! ... ~~ A use case for line based acceptance: !
For jetbrains IDE's you can use my plugin () You press CTRL+ALT+D and it will complete the sentence word by word. So in your example you press it 3 times (you'll be after "to", then you type "have a per" and you can continue with the shortcut 3 more times on the new completion text. Or just "TAB" if all is good after your intervention, it doesn't block you from using the default behavior of copilot Though the plugin only works on IntelliJ IDE's (you need to install 'LivePlugin' and 'Stewardess')
I love this suggestion. I encounter the scenario of wanting to only accept a suggestion partially a lot.
would you prefer word-by-word partial acceptance or line-by-line?


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


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This is essentially a more general issue of the closed Markdown styling support are missing in the following, missing bold and italic: Solarized Light Red Abyss Solarized Dark Tomrrow Night Blue See screenshot below for an example. For High Contrast, section heading () are not in bold. I am unclear if it's a bug or intentional. Screenshot for Solarized Dark !
Hi, I tried bold and italic with these themes: theme-tomorrow-night-blue theme-solarized-dark theme-solarized-light theme-red theme-kimbie-dark theme-abyss hcblackdefaults(High Contrast)


Issue Type: <bBug</bRelated to and Steps to reproduce: and or corresponding JS settings. Create new TS or JS file and paste next code: and ! TS Version 4.4.0-dev. VS Code version: Code - Insiders 1.59.0-insider (, 2021-07-28T05:13:47.114Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/assign
/ Can you please take a look? I believe that folding generates two new requests for inlay hints that VS Code then displays incorrectly. Here's the TS server trace from folding with only : The position of the hints seem correct to me. I don't know why VS Code requests the hints twice here though (or why it needs to re-request any hints on folding in this case since no new code became visible)
These are the visible ranges: ! And vscode sends two requests, one for each range. For some reason, each reuqest returns one inlay hint, so in total, there are 2 inlay hints: ! do you have an idea why this is? To me, it looks like a bug in the provider, there should not be a result for the second request.
Emmmmmm... I think I know the reason. In the tsserver. For each request, we will get the hint in the area that overlay with the visible range (not strictly included). Honestly, I don't know about this behavior. We may could de-duplicate these items?
Can't you just filter out all inlay hints whose position is not in the requested range?
Well, do you prefer to do it in vscode or ts side?
Hmm, maybe actually in vscode.
Verified fixed with TypeScript Nightly in


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


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
!


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


Type: <bBug</bHi, My name is Ebrima Mbye. I have been using this wonderful IDE for some while now. However, recently I have noticed that when I run a program, the output in the terminal window does also include the memory location of the file or folder I am working on. Sample output: "93c9--e1dddca87b23PS C:UsersUserDesktopNewEbrimaProgram" This is not a super cotly problem, but I just wanted to bring your attention to it. Thank you for your valuable time, User, Ebrima Mbye, Java programmer. VS Code version: Code 1.88.0 (, 2024-04-03T13:26:18.741Z) OS version: WindowsNT x64 10.0.


Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (44)</summaryExtensionVersion ------ codesnap1.3.4 vscode-javascript-snippet-pack0.1.6 vscode-django1.15.0 githistory0.6.20 python-environment-manager1.2.4 python-extension-pack1.7.0 code-runner0.12.2 vsc-python-indent1.18.0 kodezi2.2.2 debugpy2024.4.0 python2024.4.0 vscode-pylance2024.4.1 jupyter2024.3.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.9 vscode-jupyter-slideshow0.1.6 cmake-tools1.17.17 cpptools1.19.9 cpptools-extension-pack1.3.0 vsliveshare1.0.5918 sqltools0.28.1 sqltools-driver-mysql0.6.0 autodocstring0.6.1 vscode-python-typehint1.5.1 fabric8-analytics0.9.4 java1.29.0 LiveServer5.7.9 pythonpack0.3.0 javafx-support0.0.1 tabnine-vscode3.86.0 open-in-browser2.0.0 bootstrap4-vscode6.1.0 cmake0.0.17 intellicode-api-usage-examples0.2.8 vscodeintellicode1.3.1 vscode-java-debug0.57.0 vscode-java-dependency0.23.6 vscode-java-pack0.26.0 vscode-java-test0.41.0 vscode-maven0.44.0 jinja0.0.8 JavaScriptSnippets1.8.0 grammarly0.24.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.88.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
How may I upgrde?
I meet this problem too.


Today when I use python debugger to debug python files, something wrong happen in vscode 'Python Debug Console'. Output reads: ncher' '7541' '--' 'D:' ;-402f-491b-bdb5-ee7fdd8b6e0cncher' '7541' '--' 'D:' ;-402f-491b-bdb5-ee7fdd8b6e0cPS D:I have neven seen strange characters before. This string wants to overwrite what I want to print in python file and still appear with empty python file. ! My VSCode version is 1.88.1. Hope Greatest Microsoft Engineers will solve this problem. Thank you very much~ PS: To exclude influence of other entensions,I only use this four extensions. !
I've been having a very similar issue for the last week or so. I'm running Windows Powershell (5.1) in an integrated terminal in VS Code on Windows 10. If I run a command that wraps over to the second line of the terminal, an unfamiliar GUID along with some other characters (see red boxes in screenshot below) appears interspliced with the text of the command I just ran. Makes a little difficult to use the terminal. PS I don't encounter the same issue when running the same command windows powershell 5.1 directly (ie not as an integrated terminal in VS Code) ! VS Code version info: Version: 1.88.1 (user setup) Commit: Date: 2024-04-10T17:41:02.734Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. Powershell version info: ! Windows verison info: ! Installed extensions (both disabled -- enabling or disabling has no effect on the issue) !
Thanks for the issue, what happens if you comment out your file?
same thing happens with user commented out. !
I believe that's just your current working directory, which reflects the folder you're in. This is working as designed. You can change the behavior by tweaking your setting.


Unfortunately, it seems unchanged when set the value of as ${fileDirname}. And when clicking Run, it looks like to execute a to stop something runnning. Truthly, I would accept this strange long string in my sonsole but it wants to overwrite what has been output. So, if want to print some message in console without owerwritten, I need to add this code above the whole codes.
What if you set it to something else? Like workspace folder?
I've tried setting [] to other value with different directory and drive letters. But it only changes the initial working directory in Teriminal <pwsh, not in Integrated Terminal <Python Debug Console. Also I manually changed <Python Debug Consoleworking dir, it looks like the same problem. So it has no positive influence on this problem.
Who closed this? Why close it when the problem is not yet solved? On Tue, Apr 16, 2024, 1:53 AM Megan Rogge
does this reproduce if you disable all installed extensions?
updating my "" value in the user settings json did not resolve the issue. As I mentioned before, all installed extensions are already disabled and the issue still occurs.
I think this is the shell integration set command line nonce being passed echoed instead of being passed in with the sequence. I see 2 versions of Windows mentioned and both are Windows 10 so this makes sense here. I'm thinking we'll just not verify the command line via the nonce for conpty under Windows 10.
Are there verification steps for this?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Running any command in Windows PowerShell (v5) is the verification steps
I'm unable to repro the issue in Stable on Windows 11.
I can't even reproduce the original issue on my Windows 10 VM at home with VS Code 1.88.1. has the issue been fixed for you in the latest VS Code Insiders? You can get a copy at
Thanks for your reply.


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.


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.


And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?


Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is


Issue Type: <bBug</bmicrosoft/vscode-extension-samples the helloworld-sample folder , build, verift that its contributed "Hello World" command activates the extension and shows a notification. the vscode version references in in two places to use 1.43 minimum. code to activate function in , for example: , run, use "Hello World" command to activate. breakpoint on return line above. a folder. Explorer button or context menu to create a new file. Confirm that the event fires and your breakpoint is hit. from breakpoint. Explorer context menu to copy/paste or use drag/drop with modifier to drip as a copy. :bug: The event callback does not run, despite the API doc stating: Issue also exists in 1.64.2 VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-21T05:15:17.930Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
cc
the extension host's event is only emitting from 's event, but the explorer is using the 's , which doesn't seem to talk to the working copy service. What do you think the fix here should be? (cc
the bulk edit service is using the for its operations. If you look at , there is a bunch of usages for that service. The working copy file service is a wrapper around the file service that ensures the relevant events are emitted and can be participated on. I suspect that for the copy/paste operation or drag/drop we are possibly not using the bulk edit service but the file service directly? I suggest to make a pass over all explorer code and look for raw usages of to replace with bulk edit service. I think that would even enable undo/redo properly.
My bad, the real bug is that this block: doesn't handle events. cc
Pragmatic fix would probably to treat the same as .


a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.


I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by


Currently the scroll top position update is not context-aware, meaning when we have cell height changes, we don't know if it's because output height change, or users re-run a cell and outputs are updated/replaced, or users shift+enter to run cell and navigate to next cell. Users might have different expectations for each scenario but currently our heuristics for updating the scroll top didn't take the context into account. Let's use this issue to finalize the desired behavior of scroll top update. The polished/new design should cover [ ] Update element height API respects context (execution, execute+create, output update) [ ] Reveal API should handle out of sync view/content height Click the run button or press Ctrl+Enter to run focused cell If there is no enough room/space after the cell (e.g., the focused cell is the last cell) Users have disabled [ ] There is no output before execution, the view should scroll up to reveal the output fully [ ] Some users might want the bottom of the output to be fully revealed, when the output is larger than the viewport [ ] There is output before execution, the cell position should be persistent Users have enabled [ ] Reveal cell output If there is enough room after the cell [ ] Reveal cell output [ ] If the cell input is larger than the viewport, execute cell should reveal the output properly [ ] Collapse focused cell output should always keep the cell in viewport [ ] Type/Pasting content into focused cell should keep the cell in viewport [x] [ ] Notebook cell list reveal api might reveal a position on a cell whose view height is not synced with real editor height yet. [ ] Execute non-focused cell, should it keep the focused cell position persistent or keep the top of the target cell persistent? [ ] Non focused cell output height change should not change scroll top on scroll [ ] Shift+enter executes and moves focus to next cell, then new focused cell should always be in viewport [x] Scroll top position of inactive notebook editor should not change if the first partially visible cell's height change
I noticed an issue recently, is this related? Paste a large amount of text into a code cell The notebook scrolls down so far that the focused code cell is out of the viewport I can open a separate issue if you want
I guess what you were seeing is , I'll update the description to include this.
Couple cases discovered in the latest notebook sync.


both of these are likely tied to outputLineLimit being large @ 100 when the shift-enter behavior is set to "firstline" the events are as follows: first line of next cell is focused and shown at the bottom of the viewport output is cleared and the focused cell is pulled upwards against the currently executing cell output streams and pushes the focused cell out of the viewport. my ideal thoughts: anchor the focused cell (with setting), maintaining the first line visible. output will stream in, pushing the executing cell upwards out of the viewport shift-enter set to "fullCell" and next cell has a large output focus shifts to next cell, and the viewport exposes the bottom of the output for that cell. there is no cell editor in the viewport my thoughts: "fullCell" behavior should show the top of the next cell editor at the top of the viewport


In there is , which seems to be called every time the scroll event of the editor fires. That method seems to clear the dom node and reconstruct it unconditionally. When smooth scrolling is turned on, the scroll event fires many times per second and the call seems to take some time: ! I think if you would only rerender the sticky scroll widget when necessary (and generally try to minimize dom API accesses), we could improve the performance here easily. I think could have an equals method and would just do an early return if the new state equals the old state.
Thanks for this remark. It is a very good optimization point.


Title.
Opens on cmd+click. The external link to documentation in the first line works. !


<!-- 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 the user starts an extension defined terminal through the "Split Terminal" submenu of "New Terminal", the new terminal is always created in a new terminal tab, instead of a split. When the user opens a terminal through this menu, VS Code should override the field of the new terminal profile to make it split, as the user requested.
is this not what you're seeing or am I doing something wrong? !
Only when the custom terminal profile is created with . I have a terminal profile that is created with , that looks like this: This terminal profile is created like this:


For newcomers it would be nice if had a comment at the top stating something like "This is a generated file, don't change it manually"
Opened a PR for this as I ran into this making my first contribution today


I heavily use and love inlay hints but find their current styling too prominent for "hints" and think it harms readability and other editor features that use highlighting of words such as "highlight occurrences." Try finding highlighted occurrence of : Current: <img width="1779" alt="Screenshot 2023-06-29 at 11 51 00" src=""With less prominent hints: <img width="1779" alt="Screenshot 2023-06-29 at 11 47 31" src=""I think in the latter screenshot, inlay hints are less prominent but still as useful, as they are literally "hints" and don't need to be so prominent. If not as default, having a setting to tweak the background & color of hints would be great.
I think I've read a similar issue recently (should have the inlay-hint label).
Can be configured via and leaving it up to to tweak this further.
Updatde the default light/dark themes in to make these more subtle. Still want to keep the backgrounds since these could otherwise be confused with the ghost text in Copilot, comments in some themes, etc. <img width="422" alt="CleanShot 2023-06-29 at 11 23 35 src=""<img width="430" alt="CleanShot 2023-06-29 at 11 22 43 src=""


Steps to Repro: Search for an extension pack in extensions view (Say PHP Extension Pack) Open PHP Extension Pack in the editor Go to Extensions Pack tab Click on any extension Fails to open Close to open the editor Does not close Not sure how it happened but I had the extension pack open (as extension editor) and after a while (being on twitter) I wanted to close the editor and I saw error notifications. These are the minified stacktraces from the log the build was
Not able to repro it. Also followed the code and I do not see a path that has no extension in the input. Do you remember any steps you followed during this? Is it possible to guess what could be happening in editor land from the above stack trace?
are you using editors with preview mode, e.g. do they appear italic? Hard to say what the execution flow here is to be honest. Looks like a normal editor opening but failing to get the resource for the editor, which is used to associate the editor in the editor tabs model.
But this is happening while is trying to close the currently opened extension editor.
I don't use tabs, so I am not sure what the model then is... Yes, closing it was. I had the extension editor open, also installed the extension, then waited, and then tried to close the editor. So maybe some cleanup logic hit me or installing the extension made a different...
The preview feature works with tabs enabled or disabled. The fact that an editor is opened can be explained if you closed an editor and the next one below that editor was the extension editor. Closing an editor always means we open the previous editor unless it is the last editor. I suggest you try to figure out how it is possible that is even though it is not typed as such.
Ok
What are the verification steps for this?
Steps to repro are in the description


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD


Used the stable built on v1.42 for sanity test and I see following error ! I suspect this is because we removed the search location setting and trying to remove its value as migration
Instead of removing the setting, please deprecate it.
BTW I see this error in every window until I manually remove the setting.
To verify: to and manually set to . the window ensure that: no error notification appears search is in the panel upon reload the setting is removed from your


Create an ipynb file (with one Python cell) Save this Verify the entry exists in time line Change the language of the cell to Save this Verify we have an entry Click that item Bug On the left we need On the right there's no such entry in metadata This is incorrect. The ipynb has the above metadata. What seems to be happening is When the language changes, We serialize the ipynb and JSon contains the metadata However the model is not updated with corresponding changes to the ipynb file I.e. model change triggered =ipynb serialize to JSON =Json contains new metadtaa not in model =Missing step is to update the model again If we implement the last step, we could always end up in an infinite loop, Perhaps we should first update the model with metadata when ever we detect chagnes in the model before the save event. E.g. as part of pre-Save (onDidChangeNotebookDocument &/or onWillSaveNotebookDocument) This way, model will always be accurate and upto date when ipynb is serialized.
Easier way to explain the bug Create an ipynb file (with one Python cell) Save this Change the language of the cell to Save this The cell metadata will not contain the new metadata that exists in the ipynb JSON file. (model is not in sync with ipynb json)
Suggested Solution Perform model updates when we're about to save (or when we detect changes to model) When saving, ensure we save the metadata as is, without generating any new content I.e. JSON.stringify the metadata.
/cc
Considering that a serialize operation should not have side effects (ideally), enforcing a "save participant" from ipynb extension makes very good sense to me. We can leverage which support additional async operations, like how we handle attachment clearnup
For such critical metadata change, we might want to handle both auto save and manual save as we want the json and model to be always in sync.
Another simple repro step Create a notebook, and save this Add a new cell The latest entry in timeline will be However there's a difference, one has and the other (current model state) does not have any Again, model does not contain metadta (as this is a new cell) and ipynb JSON contains metadata when serialized.


<details<summaryInternal Notes</summaryHere's the work flow Add a cell A change event is triggered, undo redo stack is updated Last undo redo is User hits save button Working copy starts to handle the save operation Save participants start We add a save participant and update the model via a work space edit Now a new change event is triggered This results in a whole new undo redo stack The latest (last) undo redo item is Save participants done Working copy keeps track of the last as the entry for Problems Time line does not include , time line shows only I guess this is correct, However from a users perspective, the labels are never going to be meaningful as we'd always say . </details


Keeping this open as the main tracking issue as I keep an eye on error telemetry. Been quiet and haven't seen any entries in the errors site since early Feb with +
Closing this as fixed by the above linked PR's. Error telem has been quiet with no entries for ~4 weeks.


! Version: 1.85.0-insider (user setup) Commit: Date: 2023-12-01T19:00:37.339Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: WindowsNT x64 10.0.
I think that is expected, see This should behave the same for when multiple editor groups are opened in the same window.
The issue is that highlighted words remain until a new word is focused. In the main window, the highlights disappear when the word loses focus.
not for me in this case: ! Do you have a case where highlights remove to reproduce?
In the main window, If you click on a word and then on a blank line, the highlight disappears: !
my assumption here is that the other editor is over a word that then is highlighted in the floating editor. There is probably a heuristic to decide which highlight to apply. Can you double check my theory?
it doesn't matter if it's on the same word or not but I found out this only happens if the same editor is opened on the main window or in other windows (in this case the first floating editor highlights disappear after losing focus). Highlights disappear after losing focus in: Main window Single floating editor (Not opened in main window) Only the first floating editor when there are multiple (Not opened in main window)
I can reproduce but this is not a floating window issue. It reproduces even when you just have 2 editor groups opened next to each other: !
tl;dr: Setting to "off" fixes it. I'm seeing what I think is the same bug, after upgrading to 1.85.1 (first upgrade in a number of months, so I've jumped a few versions). While writing this I think there are two distinct problems. The first is when a single file is open: -click a word. It highlights that word, and in a different grey highlights the same word in rest of document. esc: nothing happens. I now need to click a blank line to get the highlights to go away. (I'm sure esc used to get rid of it before??)


The second is much more annoying, but only seems to happen when I have same file open twice, after using Split Editor Right. -click a word. It highlights that word, and (in a different shade of grey) highlights the same word in rest of window. In the other window it highlights some (but not all!) of the same word. doesn't get rid of it. Clicking a blank line does not get rid of it. All the grey highlights are there forever. the other window: still the highlights are there. I can now double-click a different word and see it highlight throughout document, click blank line gets rid of that one, but still my first set of highlights survive! only way to get rid of them is to close the editor and open it again. OR, reduce to just one window open, double-click it again, and then click a blank line. Playing around, I've noticed it does not matter which window I do the double-click in, it is the window on the right where the unwanted highlights survive. Regarding mentioned in the 1.84 release notes, searching for that in settings doesn't find anything. But I do have as mentioned in It is currently set to "singleFile" If I set it to "off", everything works as it used to. Double-click still highlights within the open file (only), and esc now cancels it again :-) BTW, testing the 3rd option, "multiFile", it appears to behave exactly as "singleFile" in every respect I described above. Anyway, switching to "off" gives me exactly the behaviour I want, so I'm happy.
Thanks for the detailed writeup! The editor highlights have been reworked to start bringing in support for semantic highlighting between multiple documents. This was primarily tested between multiple different documents and there are some bugs arising that have to do with split view of the same file. Will be addressing in the near future.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Steps for verification: Open a typescript file in split view, with content as follows: In the left panel, click the symbol. In the right panel, click the same symbol. In the right panel, click anywhere else that isn't a symbol.


choose any whitespace, etc in Stable: The highlights should disappear from the left panel, but persist in the right, even as you click around the right panel. Fixed on insiders: You should not be able to end up in a state with persistent highlights when your cursor is not on a symbol.


Steps to Reproduce: an empty window the trust editor, and trust the window the window Expected: Window is trusted Actual: Window is not trusted
This is also repros when you have the setting enabled: <img width="1024" alt="CleanShot 2021-06-08 at 08 17 39 src="https://user-"
Pushed a fix for this issue into , in case we will want to take this as a candidate for the June release.


Version: 1.94.0-insider Commit: Date: 2024-09-20T05:03:57.400Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: Set Google IME for Japanese. The cursor is not visible during typing. On almost all the platforms and all the applications, the cursor is usually visible during composition.
Hi yes thank you for opening this issue. This is caused by some code that is related to the current edit context implementation which hides the blinking cursor because there is already a blinking cursor in the visible text area shown during composition. A PR has been made to fix this.


Testing the GitHub code spaces extension remote explorer and try clicking on any of the help and feedback items bug Nothing happens In the developer tools I see:
I cannot repro this, but I do see that after installing the Codespaces extension, if I click on any of the help and feedback items, no Codespaces-related entries are displayed
I can't repro the buttons being busted, and I can't repro no Codespaces-related entries either.
what version of Codespaces to you have installed? And, can you check that it's activated?
the codespaces extension isn't * activated anymore, so in a local window after installing the codespaces extension it shouldn't be activated.
I would still expect it to be activated after clicking on the Remote explorer help and feedback items though as we run a command (ex. github.codespaces.getStartedLink in the original issue).
This is a bug in the codespaces extension, it's because the extension doesn't declare in its or . This used to be fine because of * activation but after we removed that the extension no longer activates timely. I'll open a PR to fix.
Workaround is to switch to the GitHub Codespaces view in the remote explorer or execute any of its commands, which will cause the extension to activate.
Hm I'm still seeing this even after reloading. Codespaces version: v1.14.0. Currently not running
Even with my PR to the Codespaces extension, we need an additional fix in remote help land. Today there is a raced timeout of 500ms and we just return after that. Since the Codespaces extension now activates on demand (and usually takes more than 500ms to activate), this means that the empty string gets cached as its url value. Since the extension will eventually activate and the command will return a value, I'd propose that we update with the resolved value at that point. To the user this will manifest as the picker populating with more values as extensions finish activating (which IMO is fine as that is how our other menus behave as when clauses are evaluated for extension-contributed commands).
<!-- 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!
This should be verifiable in the latest Insiders and with the latest GitHub Codespaces release from earlier today.
Are the repro steps just latest codespaces extension remote explorer to click on help/feedback items Or is there more to it?
yeah that's it!


Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) 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 --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.64.0-insider () In the Catch2 C++ test framework it is possible to have multiple test results for the same test in one run. This happens for example for the following code: In this scenario, the section "S" is run twice, and the first time it fails, the second time it succeeds. The C++ TestMate extension will see the two test runs, and call for the first one, and for the second, with the same for both calls. This results in the confusing display that the section is green, even though it shows a failure inside: <img width="653" alt="image" src="https://user-" does it make sense to change and (et al) so that when called multiple times, it sets the item's state to the max of the old and the new state? This seems to be analogous to what happens with the test messages (they are appended, and doesn't clear them). Or would you say it's the extension's responsibility to not set the state more than once for a given TestItem? (Cc Or maybe it is even Catch2's responsibility to accumulate the results for any section that is run more than once?
IMHO, Catch2 reports it and definitely not the responsibility of vscode. It leaves it to me.. (Though I don't know how I can solve this properly)
Why definitely? It doesn't seem so unreasonable to me. As I said, it already does something similar with the test messages.
As I think of it, vscode part is just the UI, the controlling is in my hand. More precisely and . the test provider is the .


I'm not so sure in this case. VS Code is also responsible for setting T's state correctly, you don't do that at all (as far as I'm aware). And note that it gets that one right, so it has some logic already for computing the resulting state of all child runs if there are multiple for the same item.
I would be very interested in your opinion on this.
Yea, I think it would be reasonable to no-op if the extension tries to change the test state to one with a lower priority. For instance, going from passed-skipped or failed-passed.
can you add some steps?
the test sample: this block F5.Verify that, with these changes, test that should pass remain passed in the UI, and tests that failed remain failed.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --Description: As of 1.44, I am not able to open multiple files from "Go to file..." menu (ctrl + p shortcut) when middle mouse clicked on them. I used it when opening similiar/dependent files (ts, html and css for component, etc.) As of 1.44 middle mouse click only opens last file clicked. Steps to Reproduce: dependented files (.html, .ts and .css) with same name. for that name in "Go to file..." (ctrl+p shortcut). mouse click on multiple files. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44 OS Version: Windows_NT x64 10.0.
I found that holding alt + middle mouse button does open multiple files in 1.44. If it is not regression please fill free to close it.
Workaround: configure in settings.


Testing open execute a cell that shows issues select copy output no output is copied I'd except that this "just works", at least for its text/markdown output representation


It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue


I've verified that I can see the terminal hint in insiders. Does this also need to be tested in stable?
Yes this needs a stable build as it checks quality. You could verify out of sources by setting quality to stable as well


Can this support right click to toggle the setting to hidden? !
right click shows our terminal context menu, perhaps we should just put it in there rather than adding a new one? !
this isn't a feature the others offer, thus not a bug IMO


run voice over open terminal start accessibility help via while it start reading select :bug: the reading continues all way to the end
I'm not sure we can / should prevent this from happening. Screen reader users have a way to abort the reading of certain contents. or might have insight here
This is very strange. The behavior is as if Voiceover wasn't detecting the change of context. In other words, upon pressing Escape, Voiceover is not detecting that focus is moving from one control to a different one. This is often related to focus events that are not happening. I have a question. Is the terminal accessible help somehow being removed from the DOM or hidden from accessibility without removing focus first? When debugging with NVDA, the first thing that happens after pressing Escape is an exception, as if the screen reader had lost access to something that should be there (DEBUGWARNING - NVDAObjects.IAccessible.IAccessible.getIAccessibleRole (15:05:00.655) - MainThread (5320): accRole failed: (-, 'Unspecified error', (None, None, None, 0, None)) ). Voiceover not stopping upon closing the accessibility help not only happens in the terminal. It also happens in the editor, the copilot chat and anywhere we call the accessibility help. Another thing I have observed is that, if I press f1 from the editor, I hear the name terminal accessibility help even though the terminal is not in focus and the content is related to the editor. This happens in both Windows and macOs. Finally, I have also observed that the command Open accessibility help doesn't show up in the command palette on the mac side for me, although pressing Option +F1 opens it.
Thanks for your findings You hear terminal accessibility help because I accidentally had that as the aria label. Fixed here I will comment on the others in a bit
This wasn't showing up there 2 days ago - are you on the latest insider's?
accRole failed: (-, 'Unspecified error', (None, None, None, 0, None)) Yep, we were closing the context view before calling , which is the function that focuses the other element. Will fix
Hm, that didn't fix it. What fixes it is after pressing escape, moving my cursor in the editor.


is correct though
It says you are currently on a application, inside of web content. When the editor is focused. !
Right. From the VO perspective, VS Code is a website.
Hovers use the context view service as well - they handle this correctly though when escape is used. that is done here. we probably need something similar
I clearly had not updated when I thought I had done so. I'm in the latest now and the command is showing up.
Great, thanks for the debugging. This issue should be fixed shortly.
That didn't work either, going to keep trying.
Ok so hiding the context view sets to and the element's display to . but for some reason, the screen reader continues to focus on that
Figured something out - when I use , then it works. So this is a timing issue
This seemed to work correctly for me... though my ESC button is a part of the touchbar so I have to do extra steps when VoiceOver is on to actually trigger ESC.


Do we do this for other widgets? It seemed off to me at first sight. <img width="405" alt="CleanShot 2022-10-04 at 09 58 26 src="https://user-"


When rendering Markdown preview, Unicode newline characters U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are replaced with an empty string at the source preprocessing stage. This behavior was introduced in to but it breaks the document in multiple ways: double-click word selection does not work as expected, screen readers may announce the text incorrectly, line wrapping and hyphenation does not work correctly, markdown-it plugins that rely on or may work incorrectly, even linkify fails: and so on. Since then it was fixed at the markdown-it side, and is no longer needed: It would be better to revert this change, and keep the Markdown source as is before feeding it to the parser. Steps to reproduce: a Markdown document like this: preview: Expected result: LS and PS are displayed as is, links end at Unicode newlines. Actual result: no Unicode newline characters displayed, links also consume the immediately following word. <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: WindowsNT x64 10.0.
<!-- 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!


The call was removed in
It's weird, seems like in stable we should be leaking terminal processes then but I see them shut down immediately after closing the window in stable...


Type: <bBug</bI have noticed two problems with my vscode-insiders installation which I assume may form one issue. a notebook in nbformat 4.5 is opened, new cells do not receive cell ids, even though this is required by the format spec and is a documented feature of vscode: a new notebook is created, the format is always 4.2. I am not sure whether this is expected. Steps to reproduce: a notebook with jupyterlab or any other way (jupytext etc.), and verify that it has nbformat = 4.5 the notebook in vscode, and generate a new cell, then save. the JSON of the saved notebook - the new cell does not have a cell id. Some additional points which may be of interest The issue persists when all extensions except jupyter/python are disabled. I have recent versions of nbformat etc. installed, but I would assume this is bundled with vscode anyway. The issue also exists on the current pre-release version of the jupyter extension. I haven't found any configuration option which would enable or disable support of notebook formats 4.2 Maybe I have missed a configuration option which I should have set? VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-23T05:33:33.712Z) OS version: Linux x64 6.2.0-35-generic Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ vscode-neovim0.9.1 vscode-eslint2.4.2 githistory0.6.20 fuzzy-search0.0.3 black-formatter2023.5. python2023.19. vscode-pylance2023.7.40 jupyter2023.10. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 remote-ssh0.107. remote-ssh-edit0.86.0 remote-explorer0.5. remote-server1.5.


even-better-toml0.19.2 my-vscode-utils0.0.2 pyexec0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thank you for filing this issue and sorry you are running into this. I can replicate this at my end as well. Will look into this.


see gif open GH notebook with a few cell that reference a variable run peek references and select entries notice how notebook cells are being highlighted, like "Milestone Work" get selected !
I can repro in Insiders but not master, I'll check again tomorrow
This happens because of this listener: Tho, not yet sure why the selection keeps changing... Maybe some inner list event (from the references list) bubbles up to the outer list
That listener is fine, it's the nested lists
Hey do you have any thoughts on handling this? We have a list inside another list. The inner list handles the touch event properly. The outer list then handles the event and picks up the wrong index because it finds the data attribute inside the inner list in We can Make sure the event is fired on the outer list with the correct element, by fixing to check whether it's in the right list Not fire the event on the outer list at all, when we see that it originates in a different list Add some property to the list event that says it originated in a different list so the consumer can decide In this particular case, I think any of these are fine
Thinking more, I don't think that the event should ever be handled by two lists at all. Meaning we either mark the browserEvent as handled, like with preventDefault/isDefaultPrevented, or we make the list check every event to be sure that it originated in this list.
This sounds good to me. This also sounds good to me.
related when I do peek references, I see markdown cells being selected? ! Notice I'm looking for under-discussion but "Configure" is being highlighted as one of the references
From Good catch, I didn't notice that
Thanks for the quick handling!


Hi, I would like to request that upon restart vscode, the terminals can be restored. By restored, i mean the layout, the custom names, icon and color for the terminals are retained. The content DOES NOT need to be retain. Otherwise efforts to customize all the opened terminals would gone to waste when vscode is restarted. Alternatively, vscode can provide new workspace configurations, where developer can manually enter a list of terminals' custom names, Vscode, upon starting, will automatically create new terminals based on the configured list. Even better, each time, deveoper manually open a new terminal , vscode will auto update the workspace configuration file to add a new terminal to the configured list. This applies the same to renaming of terminal Hope that this can be achieved without relying on plugin. *Do note that this might not be a duplicate of other look similar kind of feature request. Cos for this request, content does not need to be preserved. And the terminal's custom names should be preserved (sadly, persistentSessionReviveProcess, does not maintain the terminal custom names)
except it doesn't save custom terminal names.
Not only it doesn't save custom terminal names, it also doesn't save icon and color.
This is meant to be supported with including content as well, there are currently some issues with it causing it to be flaky though. They might have to wait until v1.63 where we will focus on testing. Related:
fixed !
It's persisting the icon, color, name, and layout on window reload. Doesn't seem to persist icon, color, or name on restart.
Yes. My request is focusing on restart, not window reload