jiebi/CodeConvo huggingface dataset:
Code change:
import { defaultInputBoxStyles, defaultToggleStyles } from 'vs/platform/theme/browser/defaultStyles'; import { diffInserted, diffInsertedOutline, diffRemoved, diffRemovedOutline, editorFindMatchHighlight, editorFindMatchHighlightBorder, foreground, listActiveSelectionForeground, textLinkActiveForeground, textLinkForeground, toolbarActiveBackground, toolbarHoverBackground } from 'vs/platform/theme/common/colorRegistry'; import { isHighContrast } from 'vs/platform/theme/common/theme'; <del> import { IColorTheme, ICssStyleCollector, IThemeService, registerThemingParticipant, ThemeIcon } from 'vs/platform/theme/common/themeService'; </del> <ins> import { IColorTheme, ICssStyleCollector, IFileIconTheme, IThemeService, registerThemingParticipant, ThemeIcon } from 'vs/platform/theme/common/themeService'; </ins> import { IWorkspaceContextService, WorkbenchState } from 'vs/platform/workspace/common/workspace'; import { OpenFileFolderAction, OpenFolderAction } from 'vs/workbench/browser/actions/workspaceActions'; import { ResourceListDnDHandler } from 'vs/workbench/browser/dnd';

Related discussion:
text: <!-- 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: 1.72.2 OS Version: Windows 11 / MacOS Monterey Steps to Reproduce: . the icons using the command. that the arrows are still not hidden. The vscode-icons extension has a setting called , which, as the name suggests, hides the explorer arrows next to the project folders. This look something like this: ! With the introduction of the tree mode in the search panel, I would not have expected to see any explorer arrows there. Alas, the panel has the search arrows, regardless of the extension setting. ! I already opened an issue on the vscode-icons repository, which you can find .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens on 1.72.2!
Code change:
} } if (this.ui.list.ariaLabel !== ariaLabel) { <del> this.ui.list.ariaLabel = ariaLabel; </del> <ins> this.ui.list.ariaLabel = withUndefinedAsNull(ariaLabel); </ins> } this.ui.list.matchOnDescription = this.matchOnDescription; this.ui.list.matchOnDetail = this.matchOnDetail;

Related discussion:
text: cc: Type: <bBug</bSteps to reproduce: at least 2 files in VSCode. orca. ctrl+tab to switch to the next open file. In my environment orca announces something similar to the following: Is this the expected behavior? VS Code version: Code - Insiders 1.78.0-insider (, 2023-04-06T05:21:17.374Z) OS version: Linux x64 6.2.8-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-eslint2.4.0 EditorConfig0.16.4 copilot1.79. rest-client0.25.1 better-cpp-syntax1.17.2 docomment1.0.0 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.289.0 remote-ssh0.101. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.15.1 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell2023.3.3 remote-explorer0.5. vsliveshare1.0.5834 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.17. vscode-xml0.25. vscode-yaml1.12.2 sonarlint-vscode3.16.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.45.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.41.
Code change:
} } if (this.ui.list.ariaLabel !== ariaLabel) { <del> this.ui.list.ariaLabel = ariaLabel; </del> <ins> this.ui.list.ariaLabel = withUndefinedAsNull(ariaLabel); </ins> } this.ui.list.matchOnDescription = this.matchOnDescription; this.ui.list.matchOnDetail = this.matchOnDetail;

Related discussion:
text: vscode-spring-boot-dashboard0.12.0 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is happening because of the fix for I think it is behaving as designed, though will leave that with
That's a bit weird. Since experience does not visually render a placeholder. So I would not expect it gets read out.
Question is, should it say nothing, or is the aria-label for not correct and it should be ? I'm leaning "nothing" because otherwise they might have to hold down until the actual quick pick option highlighted is read out.
I have a fix out with the "nothing" idea... but would love to know what you folks think before I merge.
In version 1.77, when I press ctrl+tab, orca informs me that the focus has moved to a list box and the name of the next file is read. Imagining the following scenario: two files, a.js and b.js. start editing the a.js file. press ctlr+tab. My screen reader reads the following information: List Box, b.js. In my view this behavior would be sufficient.
It is fixed, thanks.
Code change:
font-size: 25px; } <del> .monaco-dialog-box .dialog-message-row .dialog-message-container .dialog-message-body .dialog-message .description-container { </del> <ins> #monaco-dialog-message-body > .message-body > p { display: flex; font-size: 16px; background: var(--vscode-welcomePage-tileHoverBackground); border-radius: 6px; padding: 20px; min-height: auto; word-wrap: break-word; overflow-wrap:break-word; } #monaco-dialog-message-body > .link > p { font-size: 16px; } .monaco-dialog-box > .dialog-buttons-row > .dialog-buttons > .monaco-button{ </ins> font-size: 16px; }

Related discussion:
text: Related: ! A better user experience for blocking/deferring subsequent modal dialogs needs to be implemented.
Code change:
return recent.workspace.configPath; } <del> private indexOfWorkspace(recents: IRecent[], candidate: IWorkspaceIdentifier): number { return recents.findIndex(recent => isRecentWorkspace(recent) && recent.workspace.id === candidate.id); </del> <ins> private containsWorkspace(recents: IRecent[], candidate: IWorkspaceIdentifier): boolean { return !!recents.find(recent => isRecentWorkspace(recent) && recent.workspace.id === candidate.id); </ins> } <del> private indexOfFolder(recents: IRecent[], candidate: URI): number { return recents.findIndex(recent => isRecentFolder(recent) && extUriBiasedIgnorePathCase.isEqual(recent.folderUri, candidate)); </del> <ins> private containsFolder(recents: IRecent[], candidate: URI): boolean { return !!recents.find(recent => isRecentFolder(recent) && extUriBiasedIgnorePathCase.isEqual(recent.folderUri, candidate)); </ins> } <del> private indexOfFile(recents: IRecentFile[], candidate: URI): number { return recents.findIndex(recent => extUriBiasedIgnorePathCase.isEqual(recent.fileUri, candidate)); </del> <ins> private containsFile(recents: IRecentFile[], candidate: URI): boolean { return !!recents.find(recent => extUriBiasedIgnorePathCase.isEqual(recent.fileUri, candidate)); </ins> } //#endregion

Related discussion:
text: The steps are outlined here:
<!-- 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
Thanks!
Code change:
const visibleIndex = i + 1; KeybindingsRegistry.registerCommandAndKeybindingRule({ <del> id: 'workbench.action.openEditorAtIndex' + visibleIndex, </del> <ins> id: OPEN_EDITOR_AT_INDEX_COMMAND_ID + visibleIndex, </ins> weight: KeybindingWeight.WorkbenchContrib, when: void 0, primary: KeyMod.Alt | toKeyCode(visibleIndex), mac: { primary: KeyMod.WinCtrl | toKeyCode(visibleIndex) }, <del> handler: accessor => { const editorService = accessor.get(IEditorService); const activeControl = editorService.activeControl; if (activeControl) { const editor = activeControl.group.getEditor(editorIndex); if (editor) { return editorService.openEditor(editor).then(() => void 0); } } return void 0; } </del> <ins> handler: accessor => openEditorAtIndex(accessor, editorIndex) </ins> }); }

Related discussion:
text: I am forming an openEditorAtIndex command using the following syntax: '' + index 1-9 work correctly (and are default keybindings already). Would it be possible to add support for any index? I currently need to use this command if <= 9 and if 9, I have to go to index 9 and then next count - 9 times to get to the desired pane with a risk of wrapping around
trying to understand the scenario here, I do not think it makes sense for VSCode to introduce commands for more indices because this number is pretty much unlimited. Can we have another command that just goes to the next index, from the current one and you could use that instead? E.g. does it work if you use ?
Lines 55 - 89 are what I use to be able to go to any tab My case here is what I am trying to avoid Ideally I could do and never think twice about it The problem with using nextEditorInGroup is that I have no way of knowing the max editor number index, so if I say go to tab 10 and there are only 8 tabs, the current logic will try to go to tab 9 with the absolute exposed command, then use a nextEditorInGroup command.
that switch-case statement looks quite horrible, an alternative would be for the workbench to expose a command where you just pass the index as argument into. We already have that for other commands, e.g. see the "move editor command" () Would that be better?
That would work for me too! It is not very urgent since I don't think people navigate to tabs they can't see very often but for completeness it would be nice! Thanks!
Great. I would accept a reasonable small PR on this feature request.
I'll try to write a reasonable small PR for this :)
landed, thanks to
Some steps so I do not have to read the whole discussion? What command with what arguments should do what now?
here you go: write an extension that executes and verify the tab at that index opens.
Works nicely. Though the counting starts from - might be a bit confusing.
Ah yeah good point, but I think that is fine.
Code change:
if (SnakeCaseAction.caseBoundary.isSupported() && SnakeCaseAction.singleLetters.isSupported()) { registerEditorAction(SnakeCaseAction); } <ins> if (CamelCaseAction.wordBoundary.isSupported()) { registerEditorAction(CamelCaseAction); } </ins> if (TitleCaseAction.titleBoundary.isSupported()) { registerEditorAction(TitleCaseAction); }

Related discussion:
text: <!-- 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. --There is Title Case, Snake Case, Lowercase, Uppercase, but no Camel Case. It would be nice to transform: -
It would be a great feature. You could use that extension: until then. I also think that they should work on the to exclude articles and even custom words. instead of which is not accaptable in many academic organizations.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -a7ce-58b9-b1f9- --This feature request has not yet received the 20 community it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
Up for a PR anyone?
I to do this. I have more details in the PR description about how different use cases should be handled. I don't really have a strong opinion on it. I wrote a personal extension long ago that has it's own set of rules, so I probably will keep using that over the one I implemented in the PR.
Code change:
onDidChangeShellType: Event<TerminalShellType>; onDidChangeVisibility: Event<boolean>; <ins> onWillPaste: Event<string>; onDidPaste: Event<string>; </ins> /** * An event that fires when a terminal is dropped on this instance via drag and drop. */

Related discussion:
text: Steps to Reproduce: text into PowerShell (with Terminal suggest enabled) see batched pasting behavior
maybe related to
Haha, I think this is it triggering completions while the pasted text is being send then kicking in. Pastes should never trigger completions so let's track that here.
When verifying make sure you're on macOS.
Code change:
this.textArea.setAttribute('aria-label', this._getAriaLabel(options)); this.textArea.setAttribute('tabindex', String(options.get(EditorOption.tabIndex))); <del> if (e.hasChanged(EditorOption.domReadOnly)) { if (options.get(EditorOption.domReadOnly)) { </del> <ins> if (e.hasChanged(EditorOption.domReadOnly) || e.hasChanged(EditorOption.readOnly)) { if (options.get(EditorOption.domReadOnly) && options.get(EditorOption.readOnly)) { </ins> this.textArea.setAttribute('readonly', 'true'); } else { this.textArea.removeAttribute('readonly');

Related discussion:
text: <!-- 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. --- VS Code Version: 1.56.0-insider OS Version: MacOS Big Sur 11.2.3 Steps to Reproduce: Settings and and editor it manually. a rule: editors can't be edited anymore. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
Code change:
*--------------------------------------------------------------------------------------------*/ import { mapFindFirst } from 'vs/base/common/arraysFind'; <del> import { BugIndicatingError, onUnexpectedExternalError } from 'vs/base/common/errors'; </del> <ins> import { BugIndicatingError, onUnexpectedError, onUnexpectedExternalError } from 'vs/base/common/errors'; </ins> import { Disposable } from 'vs/base/common/lifecycle'; import { IObservable, IReader, ITransaction, autorun, derived, derivedHandleChanges, derivedOpts, recomputeInitiallyAndOnChange, observableSignal, observableValue, subtransaction, transaction } from 'vs/base/common/observable'; import { commonPrefixLength, splitLinesIncludeSeparators } from 'vs/base/common/strings';

Related discussion:
text: There is a injected text that is left over on line 52: <img width="883" alt="image" src=""Saw this stack-trace, I'm not sure if it's related or not:
I am trying to reproduce this issue but am currently not able to. Do you know what is the file you were triggering inline completions on, and what inline completions you saw ?
Code change:
private readonly _capabilities: ITerminalCapabilityStore, private readonly _processManager: Pick<ITerminalProcessManager, 'initialCwd' | 'os' | 'remoteAuthority' | 'userHome'> & { backend?: Pick<ITerminalBackend, 'getWslPath'> }, private readonly _linkResolver: ITerminalLinkResolver, <ins> @ILogService private readonly _logService: ILogService, </ins> @IUriIdentityService private readonly _uriIdentityService: IUriIdentityService, @IWorkspaceContextService private readonly _workspaceContextService: IWorkspaceContextService ) {

Related discussion:
text: <!-- 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? !
Code change:
private readonly _capabilities: ITerminalCapabilityStore, private readonly _processManager: Pick<ITerminalProcessManager, 'initialCwd' | 'os' | 'remoteAuthority' | 'userHome'> & { backend?: Pick<ITerminalBackend, 'getWslPath'> }, private readonly _linkResolver: ITerminalLinkResolver, <ins> @ILogService private readonly _logService: ILogService, </ins> @IUriIdentityService private readonly _uriIdentityService: IUriIdentityService, @IWorkspaceContextService private readonly _workspaceContextService: IWorkspaceContextService ) {

Related discussion:
text: 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!
Code change:
private readonly _capabilities: ITerminalCapabilityStore, private readonly _processManager: Pick<ITerminalProcessManager, 'initialCwd' | 'os' | 'remoteAuthority' | 'userHome'> & { backend?: Pick<ITerminalBackend, 'getWslPath'> }, private readonly _linkResolver: ITerminalLinkResolver, <ins> @ILogService private readonly _logService: ILogService, </ins> @IUriIdentityService private readonly _uriIdentityService: IUriIdentityService, @IWorkspaceContextService private readonly _workspaceContextService: IWorkspaceContextService ) {

Related discussion:
text: 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