jiebi/CodeConvo huggingface dataset:
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.
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.
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
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.
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!
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.
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
Issue Type: <bBug</bWhen pressing F8 in editor without error markers in current file, tab will switch to another opened file with error. Is it possible to prevent tab switching when F8 is pressed and there is no errors in current file? VS Code version: Code 1.22.0 (, 2018-04-05T17:25:43.982Z) OS version: Darwin x64 16.7.0 <!-- generated by issue reporter --
It's caused by a change in behavior in 1.22 (). I think it's a change to the worse: it's very easy to get used to hitting F8 to get a quick feedback for whether the current file has any errors, and this change breaks this workflow in a very noisy way. It also punishes those who work on 'dirty' projects with lots of errors and prefer to concentrate on one file at a time. I think it would be great to have a config switch for "F8 checks all files/current file", or at least a pair of keyboard bindings for the old behavior. I'm actually surprised that it wasn't implemented with this change.
Understood. The goal was to keep the number of setting low, but I understand the different use-cases and muscle memory. Until then, a workaround, albeit weak, is to hit Shift+F8 which takes to back to the file.
Yeah, I agree that "convention over configuration" has its benefits, and it seems that the suggestion that caused this change was quite popular, but IMO this warrants at least a pair of shortcut bindings. Speaking about conventions, I've just checked that for example similar shortcuts in PyCharm (and I assume all other JetBrains IDEs) only jump through errors in the current file. One upside of the old behavior was that when the current file had no errors, there were no visual changes after pressing F8, and the cursor stayed where it was. Now in this case Shift+F8 after F8 won't even bring you back to that file, it would jump to another file with errors. "Go Back" or "Open Next Recently Used Editor" works though. It was also very useful that F8 would wrap around and bring you to the first error in the current file if you are working near the end of it and did some changes that e.g. made some imports or vars unused.