jiebi/CodeConvo huggingface dataset:
With this change, , it just says 'Accessible View', but when I use the keybindings to go to next/previous, I only hear the new suggestion via as expected.
That’s odd. I still hear that redundant label info in Accessible View for inline suggestion when pressing Alt+[ and Alt+]. I have tested with NVDA and JAWS on Windows 11.
What happens for me is: inline completion accessible view "Accessible View, edit text...." 's some delay before the screen reader moves on from reading the initial text then I'm alerted with the new suggestion
If we wanted to prevent this delay, we'd need to hide the context view, wait 50 ms, reshow it. The issue with that is then it would do exactly what you describe and read the aria label + edit text before reading the new suggestion. That's what was happening in insider's yesterday and I realized was not ideal, so changed it.
can you reproduce this in today's Insiders?
it is working for me as described. I also debug with NVDA, and confirmed that it is processing the focus events before the liveRegionChange event. However, if I use Alt + left or right brackets, it behaves as we expect. If you hide the accessible view for 50 ms it might work, simply because NVDA will not receive any focus event before the alert.
I get slightly nervous about being so prescriptive when it goes to screen reader behavior. You just need a small change in the way the screen reader handle things for all these hacks to turn against us. There are a few that I feel comfortable recommending.
Thanks for confirming I've only tried macOS/ VoiceOver, so maybe the repro happens only when using NVDA. Here was the change where I had that delay
I can bring that change back if it seems reasonable to you. It's just like the other one that you tested and said works well
we still need to setup self hosting for you .
Oh yes. self-hosting is fun.
Needs to be fixed to reproduce the issue Repro: log level of "Pty Host" specifically to trace a terminal to verify trace logs show up in pty host channel the restart pty host command a terminal to verify trace logs show up in pty host channel, they don't show up
some help would be appreciated here. When the process is restarted the logging just stops working completely. Here's where the utility process environment is created: Here's the logger initialization on the pty host proc: If you try repro you'll need this change
I can reproduce it.
It seems pty process is creating the log file in a new folder instead in the logs home folder. <img width="386" alt="image" src=""It is because a new folder is getting passed to the pty process from main process. Fixing that would fix this.
Weird. Thanks, I'll look into that
This is causing following regression - only last 5 log sessions are being retained instead of 10. Hence moved it to current milestone and prepared a fix for it.
so the logs do show up, but the terminal doesn't seem to get created correctly - I cannot type in it. EDIT: after restarting the pty host, I cannot type in any of the terminals.
the terminal created before the pty host restarted receives input but does not display it. the one created after it restarted does not receive it.
I don't see this log
I ran it again and now can type in the terminals, but there are no logs happening when I type or create a new terminal !
As long as the regression fixed in is good, this is low priority. Will check it out again in July.
Flaky repro, but sometimes a window might not ack the restart. See the bg window correctly shows the restart and relaunches, but the fg doesn't: <img width="1008" alt="Screenshot 2023-06-30 at 8 02 18 am" src=""Restarting again fixes it, I can't repro any problem with the log not working though.
Weird, when this happens data events aren't getting fired for just one window: !
On input in the broken terminal: <img width="747" alt="Screenshot 2023-06-30 at 8 31 15 am" src=""
The 2 windows are connected to 2 different pty hosts: <img width="989" alt="Screenshot 2023-06-30 at 8 38 10 am" src=""
I'm closing this issue off again as the logging problem was fixed in the linked commit. I investigated the problem hit and created some more targeted issues to fix:
Issue Type: <bBug</bWhen : one mouse wheel scroll in extension view: moves 100px one mouse wheel scroll in settings editor: moves 100px When : one mouse wheel scroll in extension view: moves 100px, with slight animation one mouse wheel scroll in settings editor: moves 15~25px, without animation I'm using a Logitech G502 Lightspeed mouse, without any scrolling tweaking softwares. ! VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-05T05:30:25.429Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I don't see this, any idea
I believe this setting is ignored for macOS. Duplicate of
Actually not a duplicate. Interesting. I need to get my hands on a mouse to see if I can repro.
Created a PR that fixes this:
Light themes have relatively low contrast for foreground and hover colors. ideally we do not need to create a new color. Either we can tweak the default list colors which are used for quick pick , SelectBox, Explorer et cetera. Light Default: ! Bad Hover contrast: ! I suggest we increase the contrast for the default listHoverBackground applicable to all users. For the foreground color we could make this slightly darker again for the default. I don't see why we would create new colors either, I think whatever is good for selectBox should be the same and good for the quick pick Tagging this "under discussion" hopefully that is correct.
I finally figured out the listFocusForeground has no default, it's inherited from Monaco-shell. If we define it and listFocusHover in light-defaults we won't create any other colors. Screenshot does not do justice to foreground, you probably want to try it on your own machines. Let me know what you guys think. Below light+ with foreground, hover darkened: foreground === originally hover === # !
can you make a PR for me to try out your suggested color change?
When I use the command line code --install-extension {id} Cannot find the installed extension Vscode - userdata: $HOME /. Vscode/extensions/extensions. The json. This error only appears in version 1.90.0, but does not exist if you go back to version 1.89.0.
This only happened the first time, and it worked the second time I executed the command line to install the plugin. So did everyone else around
Are you still seeing this issue? If so can you please provide steps to reproduce?
My plug-in is a private plug-in that updates through the code command. When I released the updated version of the plug-in, I used the code command to update it, and there would be an error the first time, and it would be successful the second time, which was stable. !
TLDR: The issue happens when a version that was installed before is installed again I have pretty much the same scenario. A private extension that uses to update itself when a new version is available. This is the error that's logged: I do have an entry for my extension in the file though: I did some testing on a bare project to understand the failure mechanism. What I found out is that if a particular version of the extension is installed before (for example during my testing before I release the extension) then upgrading/downgrading to that version will fail. Using following steps I can reproduce this issue reliably: 1- Create a bare project: 2- Package the extension: 3- Increment the version number, and package again: 4- Install the first package: 5- Update to second package: So far everything is in order. The problem begins when we try to install any of those packages again: 6- Downgrade to first package: At this point the neither 0.0.1 nor 0.0.2 is shown as installed. So installing any of them will be successful. this explains why you're always getting the error on the first, but the second round is successful. 7- Install the first package again: 8- Update to second package again: Tested this with Windows and WSL Ubuntu. Happens only on WSL Ubuntu in my case.
<!-- 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.
Testing microsoft/vscode-jupyter The setting description says that the 'interactive window session' is restored. But after a reload, it seems that the state has been forgotten e.g. Open the interactive window run run prints 9 reload the window the output is restored but running again will show Note that I had to retype print(x) as there was no way to rerun the previously shown cells What's restored seems to be the last output. Maybe the settings description can clarify that?
<!-- 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?: No, issue is with extension contributed context menus. <!-- 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.89.0-insider OS Version: Mac OS X (ARM) Steps to Reproduce: a context menu in Stable and compare it to the same menu in Insiders. I verified the issue reproduces for multiple extensions including GitLens. Stable: <img width="424" alt="image" src=""Insiders: <img width="420" alt="image" src=""
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
Bisect points to My money would be on Reproduces by looking at the context menu of "Commits" when GitLens is installed: !
Notice how for the task terminal it jumps all the way to the top on the first ctrl+up, instead of going to the most recently run task: !
When I run the build task and do cmd + up, the window crashes !
That's even worse
the call to get markers here returns undefined !
I bet the markers are getting disposed of, so deleted from the map in but it looks like that wouldn't even happen since we don't set like we should. Could be why I see the renderer process crash?
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? !
A command I wrote without line/column numbers works fine: ! A command I wrote with line/column numbers works fine: !
It's a little hard to tell if this is by design or not without knowing the exact cwd and full path of these folders. What we're going for is verify if the file is real if it's relative to the current working directory (which is citro3d-rs in your last 2, not sure for the first), otherwise fall back to word links. Since you changed wordSeparators, the fall back isn't as useful, but it looks like it's working properly.
Ah sorry I forgot to include those extra details. The cwd and path was the same in all 3 cases (i.e., the relative file path should work in each case, I think?): I guess the part that doesn't make sense to me is why the latter two cases work but the first one doesn't - since in each case the path is the same and I haven't changed directories at all. I suppose the workaround of removing and from is still an option but it would be nice if the linking was more consistent.
Yeah this is strange if it's all the same cwd. I Can't repro here I'm improving trace logging in , when that is released to insiders (the day after it's merged) you will be able to set the log level via the command palette (F1) and view the trace logs when hovering the terminal line by looking in the Output panel Window dropdown entry. That will give us some more info on why this is happening.
The logging changes should be in tomorrow's insiders
thanks for that, here is the trace log output that I think is relevant for debugging. Please let me know if you need more info or another reproduction: Edit: the cwd again was and the relative path should resolve: <details<summarytrace output</summary</detailsOne odd thing I noticed - without changing any settings, I actually had one instance where it worked as expected and linked the relative path to . However I'm not sure how or why it worked. When I opened a new terminal the old behavior (not linking) came back. If I can reproduce that again I'll try to capture those trace logs and maybe it will highlight a difference in behavior that's helpful. Thanks again for looking at this!
So there's this in the logs: So it's parsed as a possible link, but not made a link candidate (which checked the file system before making the link). Somehow this part isn't adding the candidate: The only way I think that could happen is if doesn't return anything. I another log to verify the cwd and also improved fallback in case it is undefined. Can you do the same again on the next Insiders which should come out on Monday?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the delay, was a bit busy last week but I was able to check with a recent build (): The link is clickable now, even with and both in ! I'm guessing the fallback changes you did the trick. It seems the triage bot closed this as "not planned" but maybe you are able to update its status to "fixed" or similar? Thanks for your help looking into this issue!
great news! I still don't totally understand how it was failing before but at least the issue is fixed
Type: <bBug</bterminal in editor area. and hit enter. and hit enter alt+F2 to open accessible view ctrl+shift+O to open symbol list and select and hit enter Note: the focus doesn't move to VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-25T10:41:26.295Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (91)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.23.1 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.3 copilot1.115.437 copilot-chat0.8. remotehub0.60.0 vscode-github-actions0.26.2 vscode-pull-request-github0.72.0 overleaf-workshop0.2.4 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.0 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.1 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.16.0 vscode-pylance2023.9.20 jupyter2023.8.
jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.312.0 remote-ssh0.106.4 remote-ssh-edit0.86.0 remote-wsl0.81.4 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.9.2117 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.18 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.4 shinyuieditor0.4.3 quarto1.100.0 r-debugger0.5.4 java1.22.1 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.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 --
Thanks for the report! Reproduces in panel terminals also
For step 5, after I select and hit enter, the cursor moves to the beginning of the line that contains , rather than after the prompt. Is that intended behaviour?
It would be nice to have a entry in the configuration section of markdown-math extension. A place where users could put their custom math macros.
<!-- 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!
/verified
Start legacy protocol debug session Open something via "Open loaded scripts" scroll down ctrl+tab to switch to another doc ctrl+tab back to the newly opened script It's scrolled up to the top. Is it being closed/opened each time we switch away?
This problem is independent from the "Open Loaded Scripts" feature. To reproduce: debug a simple node hello world program and stop on entry in the CALL STACK select an internal module press Control-Tab twice (to switch between two editors) Observe: you loose the scroll position in the internal module
March to investigate
Workbench is not preserving scroll location of in memory resources. Same is true for diff view. Forwarding to since he probably already has an issue for this
I do but I cannot find it right now, PR welcome.
give me some code pointers for the PR and I can do it in debt week
we do it for and via the and methods that are actually defined in and we could probably push this down from and and just use it from textEditor for any input that has a resource
Ok, makes sense. Assigning to me and April to look into it
Related:
With landed, we keep the UI state when you switch editors, though we clear it when you close a tab. The rationale is that the lifecycle of these editors that have virtual resources is not known, as such we assume the view state can be ditched once the editor closes.
That sounds perfect!
Testing I'm wondering if there's a way to add a schema so that users can get descriptions on the various fields they can use while creating a new profile. I also realize that the keys represent profile names, so that might make it harder to validate/provide descriptions for them. I guess the description for the keys would go under in that case, though there already is a long description for that field.
this would be nice, looked into it a bit but we're not sure how to set it up for such an object. We essentially want to enforce something like
would you be the right person to ask about schemas for settings?
You can use the property to specify the shape of all properties regardless of the key. An example is the setting: If there are constraints on the key, you can use :
Testing Type in the settings editor. It would be nice if there was autocomplete for a list of languages. This is a finite list which we should be able to suggest fyi !
It's easier to discover language overrides in the editor because there is autocomplete there: !
Thanks to for pointing out the language service to me the other day. PR ready above.
/verified? The autocomplete works but no matter what I write there I get the same set of settings? I suppose all of these apply to all languages. ! !
Yep, the idea is for it to show all language-configurable settings. Then, the user can read and write settings for that language. I plan on making it so that the tab says which language you're on, for extra confirmation.
Type: <bBug</bterminal git bash Enter and you will get delay VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-06T08:07:13.626Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ rust-bundle1.0.0 glance0.0.8 project-manager12.8.0 redmodscript-lang0.2.0 redmodtweak-lang0.1.0 lit-html1.11.1 glsl-literal1.0.6 vscode-markdownlint0.55.0 vscode-eslint2.4.4 composer-php-vscode1.45. intelli-php-vscode0.12. phptools-vscode1.45. profiler-php-vscode1.45. rust-syntax0.6.1 gitlens14.9.1 EditorConfig0.16.4 prettier-vscode10.4.0 auto-close-tag0.5.15 auto-rename-tag0.1.10 copilot1.186.856 copilot-chat0.16. todo-tree0.0.226 path-autocomplete1.25.0 redscript-syntax-highlighting0.0.3 auto-comment-blocks1.0.1 dotenv1.0.1 debugpy2024.6.0 python2024.6.0 vscode-pylance2024.4.1 remote-wsl0.88.2 hexeditor1.10.0 vscode-extension-auto-import1.4.3 indent-rainbow8.3.1 vscode-yaml1.14.0 rust-analyzer0.3.1950 crates0.6.6 shader1.1.5 vscode-styled-components1.7.8 vscode-stylelint1.4.0 vscode-mdx1.8.4 highlight-matching-tag0.11.0 vscode-import-cost3.3.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
does this reproduce if you disable shell integration, ?
If I uncheck Shell Integration, it works well after terminal restart.
I have more details in with what's going wrong.