jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> // Handle empty to open (only if no other window opened) if (usedWindows.length === 0 || filesToOpen) { if (filesToOpen && !emptyToOpen) { emptyToOpen++; } </del> <ins> // Open empty window either if enforced or when files still have to open if (filesToOpen || openOneEmptyWindow) { </ins> const remoteAuthority = filesToOpen ? filesToOpen.remoteAuthority : openConfig.remoteAuthority; <del> for (let i = 0; i < emptyToOpen; i++) { addUsedWindow(await this.doOpenEmpty(openConfig, openFolderInNewWindow, remoteAuthority, filesToOpen), !!filesToOpen); // any other window to open must open in new window then openFolderInNewWindow = true; } </del> <ins> addUsedWindow(await this.doOpenEmpty(openConfig, openFolderInNewWindow, remoteAuthority, filesToOpen), !!filesToOpen); </ins> } return { windows: distinct(usedWindows), filesOpenedInWindow };

Related discussion:
text: Steps to Reproduce: to 1 window on a folder open the command line run = only the folder opens, but not an empty window I would expect here 2 windows to open, one is the folder and one the empty window since no argument was given to open any folder or file.
Code change:
} .action-widget .monaco-list .monaco-list-row.action.focused:not(.option-disabled) { <del> background-color: var(--vscode-quickInputList-focusBackground); </del> <ins> background-color: var(--vscode-quickInputList-focusBackground) !important; </ins> color: var(--vscode-quickInputList-focusForeground); outline: 1px solid var(--vscode-menu-selectionBorder, transparent); outline-offset: -1px; } .action-widget .monaco-list-row.group-header { <del> color: var(--vscode-pickerGroup-foreground); </del> <ins> color: var(--vscode-pickerGroup-foreground) !important; </ins> font-weight: 600; }

Related discussion:
text: I'm using Light+. ! Could this be caused by bundling issues?
I also see this in oss. Seems like a somewhat recent regression
Code change:
id: 'breadcrumbs.toggle', title: { value: localize('cmd.toggle', "Toggle Breadcrumbs"), <del> mnemonicTitle: localize('miBreadcrumbs', "Toggle &&Breadcrumbs"), </del> <ins> mnemonicTitle: localize({ key: 'miBreadcrumbs', comment: ['&& denotes a mnemonic'] }, "Toggle &&Breadcrumbs"), </ins> original: 'Toggle Breadcrumbs', }, category: Categories.View, toggled: { condition: ContextKeyExpr.equals('config.breadcrumbs.enabled', true), title: localize('cmd.toggle2', "Breadcrumbs"), <del> mnemonicTitle: localize('miBreadcrumbs2', "&&Breadcrumbs") </del> <ins> mnemonicTitle: localize({ key: 'miBreadcrumbs2', comment: ['&& denotes a mnemonic'] }, "&&Breadcrumbs") </ins> }, menu: [ { id: MenuId.CommandPalette },

Related discussion:
text: 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?
Code change:
export interface MainThreadCommandsShape extends IDisposable { $registerCommand(id: string): void; $unregisterCommand(id: string): void; <del> $executeCommand<T>(id: string, args: any[], retry: boolean): Promise<T | undefined>; </del> <ins> $executeCommand<T>(id: string, args: any[] | SerializableObjectWithBuffers<any[]>, retry: boolean): Promise<T | undefined>; </ins> $getCommands(): Promise<string[]>; }

Related discussion:
text: Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this
Code change:
<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-vs-bg{fill:#424242;}.icon-vs-action-blue{fill:#00539c;}</style></defs><title>Compare_16x</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M16,11H12.121l1.939,1.94a1.5,1.5,0,1,1-2.12,2.12L9.433,12.554A4.4,4.4,0,0,1,9,12.735V16H0V5H4.706A4.445,4.445,0,0,1,7,4.051V0h5.621L16,3.379Z" style="display: none;"/></g><g id="iconBg"><path class="icon-vs-bg" d="M15,3.793V10H11.735a4.4,4.4,0,0,0,.237-1H14V4.207L11.793,2H9V4.276a4.485,4.485,0,0,0-1-.225V1h4.207ZM7,12.949V14H2V7H3.276a4.493,4.493,0,0,1,.486-1H1v9H8V12.972A4.612,4.612,0,0,1,7.5,13,4.342,4.342,0,0,1,7,12.949Z"/></g><g id="colorAction"><path class="icon-vs-action-blue" d="M13.354,13.646l-3-3a.545.545,0,0,0-.071-.047A3.462,3.462,0,0,0,11,8.5,3.5,3.5,0,1,0,7.5,12a3.462,3.462,0,0,0,2.1-.717.57.57,0,0,0,.047.07l3,3a.5.5,0,1,0,.708-.707ZM7.5,11A2.5,2.5,0,1,1,10,8.5,2.5,2.5,0,0,1,7.5,11Z"/></g></svg> </del>  No newline at end of file <ins> <svg fill="none" height="16" viewBox="0 0 16 16" width="16" xmlns="http://www.w3.org/2000/svg"><path clip-rule="evenodd" d="m6 12h-1c-.27-.02-.48-.11-.69-.31s-.3-.42-.31-.69v-6.28c.59-.34 1-.98 1-1.72 0-1.11-.89-2-2-2s-2 .89-2 2c0 .73.41 1.38 1 1.72v6.28c.03.78.34 1.47.94 2.06s1.28.91 2.06.94c0 0 1.02 0 1 0v2l3-3-3-3zm-3-10.2c.66 0 1.2.55 1.2 1.2s-.55 1.2-1.2 1.2-1.2-.55-1.2-1.2.55-1.2 1.2-1.2zm11 9.48c0-1.73 0-6.28 0-6.28-.03-.78-.34-1.47-.94-2.06s-1.28-.91-2.06-.94h-1v-2l-3 3 3 3v-2h1c.27.02.48.11.69.31s.3.42.31.69v6.28c-.59.34-1 .98-1 1.72 0 1.11.89 2 2 2s2-.89 2-2c0-.73-.41-1.38-1-1.72zm-1 2.92c-.66 0-1.2-.55-1.2-1.2s.55-1.2 1.2-1.2 1.2.55 1.2 1.2-.55 1.2-1.2 1.2z" fill="#424242" fill-rule="evenodd"/></svg> </ins>  No newline at end of file

Related discussion:
text: Issue Type: <bFeature Request</bTo see the changes i made to a source controlled checked-in file, a user clicks on the "Open Changes" icon on the top right. I would like to see a better looking icon that represents git and changes. The current one looks like a search button. VS Code version: Code 1.29.1 (, 2018-11-15T19:13:36.375Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
What do you think? Also note that changing this will affect other users and we'll soon get "but I was accustomed to the old icon!" messages.
At first glance, the icon does appear to look like some type of "search" button. Upon inspecting it, you can see that there are two files being compared (i.e. a diff). It's hard to see these details at a quick glance, so if there is a better icon we could use I'd be up to changing that. GitHub uses these icons for diffs/compare: <img width="79" alt="image" src="https://user-"<img width="85" alt="image" src="https://user-"<img width="499" alt="image" src="https://user-"<img width="498" alt="image" src="https://user-"I do like the last one the best (though it is an octicon).
I like it. If you find me those assets, let's do it together!
Code change:
position: relative; padding: 0 6px; margin-bottom: 4px; <del> align-items: center; </del> <ins> align-items: flex-end; </ins> justify-content: space-between; }

Related discussion:
text: In VS Code action items inside inputs are vertically aligned to top, in the Chat features they are centered in the middle. This happens when putting in a lot of text or pressing Shift+Enter. Panel: <img width="425" alt="image" src=""Inline: <img width="608" alt="image" src=""Quick: <img width="621" alt="image" src=""For Inline and Quick the action items to the right of the input box should also stick to the top.
Seems like we have a mix of top-aligned and overflow w/ scroll (see below). But I agree that we should be consistent as much as possible. But it does feel like a chat send button should generally but aligned to the bottom, no? We may even consider rendering the toolbar on its own row once we're into multiple lines. That would ensure the text isn't forced to fill a tiny space now that we have 2+ icons. Here's how Teams does it as an example: ! ! ! !
Would be awesome if the text could wrap around it, especially in the narrow search widget case, I've always wanted that but I think it would be a pain to implement.
Don't have a strong opinion about top or bottom, I think each can be justified on a case-by-case basis. but middle looks weird. :) For example, inline Chat may want to do top alignment as the icons would align with those outside the input field (poppet and close) Bottom would help with the wrapping.
Code change:
const pathSeparatorClause = '/'; // '":; are allowed in paths but they are often separators so ignore them // Also disallow  to prevent a catastropic backtracking case #24798 <del> const excludedPathCharactersClause = '[^0s!$`&*()[]+'":;]'; </del> <ins> const excludedPathCharactersClause = '[^0s!$`&*()[]'":;]'; </ins> /** A regex that matches paths in the form /foo, ~/foo, ./foo, ../foo, foo/bar */ export const unixLocalLinkClause = '((' + pathPrefix + '|(' + excludedPathCharactersClause + ')+)?(' + pathSeparatorClause + '(' + excludedPathCharactersClause + ')+)+)'; export const winDrivePrefix = '(?:?)?[a-zA-Z]:'; const winPathPrefix = '(' + winDrivePrefix + '|..?|~)'; const winPathSeparatorClause = '(|/)'; <del> const winExcludedPathCharactersClause = '[^0<>?|/s!$`&*()[]+'":;]'; </del> <ins> const winExcludedPathCharactersClause = '[^0<>?|/s!$`&*()[]'":;]'; </ins> /** A regex that matches paths in the form ?c:foo c:foo, ~foo, .foo, ..foo, foobar */ export const winLocalLinkClause = '((' + winPathPrefix + '|(' + winExcludedPathCharactersClause + ')+)?(' + winPathSeparatorClause + '(' + winExcludedPathCharactersClause + ')+)+)';

Related discussion:
text: Issue Type: <bBug</bnew VSCode window new Terminal terminal: terminal: in Cmd and mouse over the two listing name. Only the /tmp/Foo.h will be clickable. won't be because of the . VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 19.3.0 <!-- generated by issue reporter --
/duplicate
Code change:
const resources: { originalUri: Uri | undefined; modifiedUri: Uri | undefined }[] = []; for (const change of stashChanges) { if (change.status === Status.INDEX_ADDED) { <del> resources.push({ originalUri: undefined, modifiedUri: toGitUri(change.uri, `stash@{${stash.index}}`) }); </del> <ins> resources.push({ originalUri: undefined, modifiedUri: toGitUri(change.uri, stash.hash) }); </ins> } else if (change.status === Status.DELETED) { <del> resources.push({ originalUri: change.uri, modifiedUri: undefined }); </del> <ins> resources.push({ originalUri: toGitUri(change.uri, stashParentCommit), modifiedUri: undefined }); </ins> } else if (change.status === Status.INDEX_RENAMED) { <del> resources.push({ originalUri: change.originalUri, modifiedUri: toGitUri(change.uri, `stash@{${stash.index}}`) }); </del> <ins> resources.push({ originalUri: toGitUri(change.originalUri, stashParentCommit), modifiedUri: toGitUri(change.uri, stash.hash) }); </ins> } else { <del> resources.push({ originalUri: change.uri, modifiedUri: toGitUri(change.uri, `stash@{${stash.index}}`) }); </del> <ins> resources.push({ originalUri: toGitUri(change.uri, stashParentCommit), modifiedUri: toGitUri(change.uri, stash.hash) }); </ins> } }

Related discussion:
text: 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=""
Code change:
} } <ins> private _onReplaceInputKeyDown(e: IKeyboardEvent): void { if (e.equals(KeyCode.Enter)) { this.replaceOne(); e.preventDefault(); return; } } </ins> protected onInputChanged(): boolean { this._state.change({ searchString: this.inputValue }, false); // this._findModel.research();

Related discussion:
text: Testing a notebook with some content the replace widget to replace an existing string enter while focused in the replace box no effect, string should be replaced as it does in a text editor
It's a bad bug, but fixing it is not trivial. Considering it's not regression, I'll fix it next week.
Code change:
import { IFileService } from 'vs/platform/files/common/files'; import { createFileStat } from 'vs/workbench/test/common/workbenchTestServices'; import { URI } from 'vs/base/common/uri'; <ins> import { ILogService, NullLogService } from 'vs/platform/log/common/log'; </ins> const unixLinks: (string | { link: string; resource: URI })[] = [ // Absolute

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:
import { IFileService } from 'vs/platform/files/common/files'; import { createFileStat } from 'vs/workbench/test/common/workbenchTestServices'; import { URI } from 'vs/base/common/uri'; <ins> import { ILogService, NullLogService } from 'vs/platform/log/common/log'; </ins> const unixLinks: (string | { link: string; resource: URI })[] = [ // Absolute

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:
import { IFileService } from 'vs/platform/files/common/files'; import { createFileStat } from 'vs/workbench/test/common/workbenchTestServices'; import { URI } from 'vs/base/common/uri'; <ins> import { ILogService, NullLogService } from 'vs/platform/log/common/log'; </ins> const unixLinks: (string | { link: string; resource: URI })[] = [ // Absolute

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
Code change:
} } <del> private onEditorClosed(listenerDispose: IDisposable, resourcesToWaitFor: URI[], waitMarkerFile: URI): void { // In wait mode, listen to changes to the editors and wait until the files // are closed that the user wants to wait for. When this happens we delete // the wait marker file to signal to the outside that editing is done. if (resourcesToWaitFor.every(resource => !this.editorService.isOpen({ resource }))) { listenerDispose.dispose(); this.fileService.del(waitMarkerFile); } } </del> private onContextMenu(e: MouseEvent): void { if (e.target instanceof HTMLElement) { const target = <HTMLElement>e.target;

Related discussion:
text: VSCode Version: 1.33.1 OS Version: 10.14.4 When editing and closing a git commit message file very quickly, the contents are not provided to git. Currently I manually save before closing any git commit file but it seems clear this should work properly - autosave should happen, then Code should inform Git that the commit file is ready. Currently it appears the two events are happening in reverse order, causing a bug. Steps to Reproduce: VS Code as editor () a git commit the commit message in Code close the commit message in Code, before autosave occurs Result: git complains about an empty commit message Expected: Autosave should happen before Code releases control back to git, resulting in a properly saved commit message Does this issue occur when all extensions are disabled?: Yes
Good catch. Extra points for using auto save in VSCode :+1:
via
Code change:
} private createSearchResultsView(container: HTMLElement): void { <del> this.resultsElement = dom.append(container, $('.results.show-file-icons')); </del> <ins> this.resultsElement = dom.append(container, $('.results.show-file-icons.file-icon-themable-tree')); </ins> const delegate = this.instantiationService.createInstance(SearchDelegate); const identityProvider: IIdentityProvider<RenderableMatch> = {

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!