jiebi/CodeConvo huggingface dataset:
Change:
import { IOpenerService } from 'vs/platform/opener/common/opener'; import { FileAccess, AppResourcePath } from 'vs/base/common/network'; import { IChecksumService } from 'vs/platform/checksum/common/checksumService'; <ins> import { ILogService } from 'vs/platform/log/common/log'; import { IBannerService } from 'vs/workbench/services/banner/browser/bannerService'; import { Codicon } from 'vs/base/common/codicons'; </ins> interface IStorageData { <del> dontShowPrompt: boolean; commit: string | undefined; </del> <ins> readonly dontShowPrompt: boolean; readonly commit: string | undefined; </ins> } class IntegrityStorage { private static readonly KEY = 'integrityService'; <del> private storageService: IStorageService; </del> private value: IStorageData | null; <del> constructor(storageService: IStorageService) { this.storageService = storageService; </del> <ins> constructor(private readonly storageService: IStorageService) { </ins> this.value = this._read(); }

Discussion:
Originally posted by in
This is a great idea: !
Previously, extensions that patched VSCode like would occasionally result in a notification only after VSCode was updated. After this change, this banner appears every time VSCode is opened, even if it was previously dismissed for the same version. This feels very obtrusive. Was that an intended part of this change? !
Banner will be removed again in , I think it will cause more harm than being useful.
Change:
import API from '../utils/api'; import { TypeScriptServiceConfiguration } from '../utils/configuration'; <del> export const localize = nls.loadMessageBundle(); </del> <ins> const localize = nls.loadMessageBundle(); </ins> export const enum TypeScriptVersionSource { Bundled = 'bundled',

Discussion:
devtools. the vscode repo and open a TS file. . over an expression while the TS extension loads. hover appears. :bug: In the devtools console, the "didn't get externalized correctly" warning shows up.
Any ideas what would cause this?
This would happen if the call wasn't rewritten by the webpack loader defined here: can you look at the built version of typescript-language-features and tell me what the call looks like?
Ah looks like we're incorrectly importing from another file. Here's the compiled call (which doesn't appear to be rewritten): Will push a PR with a fix
That'll do it. loadMessageBundle is actually responsible for giving you your strings for that specific file so you need to have one of those everywhere you have a localize call
Change:
} .monaco-shell.vs-dark [tabindex="0"]:focus, <ins> .monaco-shell.vs-dark .synthetic-focus, </ins> .monaco-shell.vs-dark select:focus, .monaco-shell.vs-dark input[type="button"]:focus, .monaco-shell.vs-dark input[type="submit"]:focus,

Discussion:
Right now, this sort of ruins the feeling of an input with options -- it becomes more like an input followed by some toggles ! -- if you have the time
! there you go
I made you a reviewer
Nice solution. Merged.
Change:
.monaco-dropdown > .dropdown-label > .action-label.disabled { cursor: default; } <ins> .monaco-dropdown-with-primary { display: flex; flex-direction: row; border-radius: 5px; } .monaco-dropdown-with-primary > .action-label { margin-right: 0; } .monaco-dropdown-with-primary > .monaco-dropdown > .dropdown-label .codicon[class*='codicon-'] { font-size: 12px; padding-left: 0px; padding-right: 0px; line-height: 16px; margin-left: -4px; } </ins>

Discussion:
For reuse by other code areas
Also polish styling including a hover over the joint buttons
Mockup: !
Fixed in
Change:
} }), DOM.addStandardDisposableListener(inputBox.inputElement, DOM.EventType.KEY_UP, (e: IKeyboardEvent) => { <del> const initialRelPath: string = relative(stat.root.resource.fsPath, stat.parent.resource.fsPath); </del> <ins> const initialRelPath: string = path.relative(stat.root.resource.fsPath, stat.parent.resource.fsPath); </ins> let projectFolderName: string = ''; if (this.contextService.getWorkbenchState() === WorkbenchState.WORKSPACE) { projectFolderName = paths.basename(stat.root.resource.fsPath);	// show root folder name in multi-folder project

Discussion:
Only one nitbit, now when we display the path in a multi folder setup we do not start with a and when we display the path in a single folder setup we show the relative folder with a at the start. I think that is wrong and the path should never show a since it is not absolute
Change:
const dateType = config.get<'committed' | 'authored'>('date'); const showAuthor = config.get<boolean>('showAuthor'); <ins> const showUncommitted = config.get<boolean>('showUncommitted'); </ins> const openComparison = localize('git.timeline.openComparison', "Open Comparison"); const items = commits.map<GitTimelineItem>((c, i) => {

Discussion:
<!-- 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. --A feature called Local History has been to show entries such as "File Saved" and "Undo/Redo" in the timeline of a file. Simultaneously, an item called "Uncommitted changes" has been removed apparently in I found the "Uncommitted changes" item very useful to quickly see the changes of a file since the last version. Current implementation with the local history feels unconvenient and does not reveal the same information as the previous Uncommited changes item did. It also compares the file with the current version on the disk and not the changes between the two versions (version in previous commit vs. saved version). So I would like to have a possibility to configure the timeline so that the previous behaviour showing the Uncommitted changes is restored.
cc I think it is reasonable to bring back the uncommitted changes when local history is disabled.
I second this!
Opened PR to have a setting for this. I do not think making this conditional on which timeline provider is showing is clever.
A new setting allows to enable this starting in tomorrows insider build.
Wow! That's great, thanks
/verified
Change:
return root.uri.fsPath; } } <ins> return roots[0].uri.fsPath; </ins> } <del> return roots[0].uri.fsPath; </del> <ins> return undefined; </ins> } public execute(command: string, args: any, expectsResultOrToken?: boolean | CancellationToken): Promise<any> {

Discussion:
VSCode Version: Code 1.19.1 (, 2017-12-19T09:46:02.926Z) OS Version: Windows_NT ia32 10.0. Extensions: Extensions are disabled Steps to Reproduce: / Interactive Playground Under heading IntelliSense, the text reads: It it unclear what error underline means, I don't see any underline or error.
I can reproduce on the 2nd time: playground tab playground No errors shown & IntelliSense not working & rename & code formatting & // ts-check ...
Yes, opening playground a second time seems to be key to all the problems I was having with it. Thanks.
VSCode Version: Code - Insiders 1.20.0-insider (, 2017-12-22T06:14:07.615Z) OS Version: Linux x64 4.9.72-1-lts Extensions: none Also happens every time for me in Interactive Playground with no extensions loaded w/ insiders on linux. If restarting vscode repeatedly, sometimes syntax highlight also fails. EDIT: As I continued on down through the document, some other instructions are failing too.
VSCode Version: Code 1.19.1 (, 2017-12-19T09:35:14.671Z) OS Version: Darwin x64 16.7.0 Extensions: none I just got VSCode for the first time, fresh install on macOS, and experienced the same issue with different features in the Interactive Playground described here by the peeps above. Don't have much to add in terms of describing/reproducing the issue, just posting here for completeness that the issue affects 1.19.1 on OSX as well.
I see this when opening without a folder. The missing errors also reproduce in an untitled file in JavaScript mode (code actions seem to work in this case). Code actions do not work in the interactive playground when the workbench is not open on a folder. Could you take a look?
Note that this still requires this upstream fix from TS ()
Change:
class CheckoutTagItem extends CheckoutItem { <del> override get label(): string { return this.ref.name || this.shortCommit; } </del> <ins> override get label(): string { return `$(tag) ${this.ref.name || this.shortCommit}`; } </ins> override get description(): string { return localize('tag at', "Tag at {0}", this.shortCommit); }

Discussion:
<img width="128" alt="CleanShot 2022-06-24 at 07 47 19 src="https://user-"<img width="230" alt="CleanShot 2022-06-24 at 07 47 05 src="https://user-"<img width="209" alt="CleanShot 2022-06-24 at 07 48 13 src="https://user-"
Added icons to all the entries so that the quick pick items are consistent. <img width="714" alt="image" src="https://user-"
I wouldn't add icons for every entry as it can get busy/repetitive. and I were just discussing about reducing the repetition of icons in quick picks and only showing them for the ones that really warrant it. <img width="488" alt="CleanShot 2022-06-24 at 12 23 12 src="https://user-"
FYI was suggesting removing the regular branch icons which it doesn't look like the change does. That would align closer with how tasks use icons (defaults are hidden) and the new debug console quick access for example.
This particular quick pick contains items of different types (ex: local branch, remote branch, tag). The only was to distinguish the type if to look at the description of the icon. I think that having an icon for each item based on its type is actually helpful here. I would like to keep it and see what the user feedback will be.
Just by looking at the icons, I'm only seeing the "locked" branch as the different one from the others. There is no difference between the local and remote branches here so I'm not seeing the benefit of showing the icon every single time and still feels very noisy: <img width="335" alt="CleanShot 2022-07-11 at 08 19 54 src="https://user-"
Reopening to track discussion
Here is what I am seeing if I am running a search for "release". I can clearly differentiate between tags, locked branches, and branches. if I would have a suitable icon for a remote branch, I would be happy to add it.

I personally still feel that there is value in showing an icon for item, especially that I think the way people interract with the branch picker is that they open it and start typing in the input to filter down to the item that they would like to open. <img width="728" alt="image" src="https://user-"
We could try to add an overlay on the branch icon, similar to VS: <img width="118" alt="CleanShot 2022-07-13 at 07 59 57 src="https://user-"
Love it! If you add this icon, I am happy to place this in the picker to indicate remote branches.
Closing this issue as I have the icon for remote branches.
Change:
return hash; } <del> export function getPermalink(gitAPI: GitAPI, hostPrefix?: string): string | undefined { </del> <ins> export function getPermalink(gitAPI: GitAPI, useSelection: boolean, hostPrefix?: string): string | undefined { </ins> hostPrefix = hostPrefix ?? 'https://github.com'; const { uri, range } = getFileAndPosition(); <del> if (!uri) { return; } const gitRepo = getRepositoryForFile(gitAPI, uri); </del> <ins> // Use the first repo if we cannot determine a repo from the uri. const gitRepo = (uri ? getRepositoryForFile(gitAPI, uri) : gitAPI.repositories[0]) ?? gitAPI.repositories[0]; </ins> if (!gitRepo) { return; }

Discussion:
Testing Of course, there may have been discussions and reasons for the current behavior, but I was surprised that the share action in the File menu linked to the line number of the currently opened editor. I was expecting a link to the workspace/repository only.
would you expect the same command from the editor context menu to use file+line number?
yes, my expectation would be the context menu has the "context" and therefore does have the file/line associated with it.
Change:
import * as glob from 'vs/base/common/glob'; import * as paths from 'vs/base/common/paths'; import uri from 'vs/base/common/uri'; <ins> import { untildify } from 'vs/base/common/labels'; </ins> import { IWorkspaceContextService, WorkbenchState } from 'vs/platform/workspace/common/workspace'; import { IPatternInfo, IQueryOptions, IFolderQuery, ISearchQuery, QueryType, ISearchConfiguration, getExcludes, pathIncludedInQuery } from 'vs/platform/search/common/search'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <ins> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; </ins> export interface ISearchPathPattern { searchPath: uri;

Discussion:
Loosely related to ! We can use the 'files to include' box to do a search in an arbitrary folder, but it has to be an absolute path. It should also work when using a ~ to indicate the user's home directory.
Change:
} __vsc_update_cwd() { <del> builtin printf 'e]633;P;Cwd=%sa' "$(__vsc_escape_value "$PWD")" </del> <ins> if [ "$__vsc_is_windows" = "1" ]; then __vsc_cwd="$(cygpath -m "$PWD")" else __vsc_cwd="$PWD" fi builtin printf 'e]633;P;Cwd=%sa' "$(__vsc_escape_value "$__vsc_cwd")" </ins> } __vsc_command_output_start() {

Discussion:
<!-- 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. --Version: 1.89.0-insider (user setup) Commit: Date: 2024-04-15T05:50:22.934Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: Git Bash with shell integration enabled a command to split the terminal !
I can work on fixing this since I created the issue adding git bash shell integration
Hi this issue still happens on the stable(1.89.1) and insider build(1.90.0). System info: Version: 1.89.1 (user setup) Commit: Date: 2024-05-07T05:13:33.891Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. !
Change:
} const resultExpression: ParsedStringPattern = function (path: string, basename?: string) { <del> for (let i = 0, n = parsedPatterns.length; i < n; i++) { </del> <ins> let resultPromises: Promise<string | null>[] | undefined = undefined; </ins> <del> // Check if pattern matches path </del> <ins> for (let i = 0, n = parsedPatterns.length; i < n; i++) { </ins> const result = parsedPatterns[i](path, basename); <del> if (result) { return result; </del> <ins> if (typeof result === 'string') { return result; // immediately return as soon as the first expression matches } // If the result is a promise, we have to keep it for // later processing and await the result properly. if (isThenable(result)) { if (!resultPromises) { resultPromises = []; } resultPromises.push(result); </ins> } } <ins> // With result promises, we have to loop over each and // await the result before we can return any result. if (resultPromises) { return (async () => { for (const resultPromise of resultPromises) { const result = await resultPromise; if (typeof result === 'string') { return result; } } return null; })(); } </ins> return null; };

Discussion:
While reviewing some code in I noticed potential issues: and Will wrongly stop the loop when the result is a even when that result resolves to . Would be good to have a test case for this too.
I think you the support for for the expression matching via , do we really still need this? I feel this makes glob matching overly complicated. Checking on usages, I think search component uses it to lazily resolve children...
PR:
Are you suggesting to resolve children before doing the glob matcher? It would be a lot faster to avoid matching children until you need them. I don't like the flexible typing of this though. It should be explicitly sync or not.
Change:
assert.equal(window.activeTextEditor!.viewColumn, ViewColumn.One); }); <ins> test('issue #27408 - showTextDocument & vscode.diff always default to ViewColumn.One', async () => { const [docA, docB, docC] = await Promise.all([ workspace.openTextDocument(await createRandomFile()), workspace.openTextDocument(await createRandomFile()), workspace.openTextDocument(await createRandomFile()) ]); await window.showTextDocument(docA, ViewColumn.One); await window.showTextDocument(docB, ViewColumn.Two); assert.ok(window.activeTextEditor); assert.ok(window.activeTextEditor!.document === docB); assert.equal(window.activeTextEditor!.viewColumn, ViewColumn.Two); await window.showTextDocument(docC, ViewColumn.Active); assert.ok(window.activeTextEditor!.document === docC); assert.equal(window.activeTextEditor!.viewColumn, ViewColumn.Two); }); </ins> test('issue #5362 - Incorrect TextEditor passed by onDidChangeTextEditorSelection', (done) => { const file10Path = join(workspace.rootPath || '', './10linefile.ts'); const file30Path = join(workspace.rootPath || '', './30linefile.ts');

Discussion:
VSCode Version: Code - Insiders 1.13.0-insider (, 2017-05-26T05:14:23.944Z) OS Version: Windows_NT ia32 10.0. These 2 apis should honor the ViewColumn if specified, but if left they should default to the column of the active editor Having this will eliminate code in many extensions such as: Which fails for anything that isn't a text document (since will be missing)
Unsure what that means?
Sorry, I meant that the could be if the actual active "editor" is a non-text document (image, extension, etc). And can be for a diff editor (maybe other cases?). So an extension can't reliably get the real "active" column
+1 for not setting as default if not specified so that we prefer the currently active editor column when documents open.
PR addresses it, but it conflicts with another change see: Any thoughts on coming to a resolution on that -- I would LOVE to see this fixed.
we have an option for editors to reveal if they are open in another group (see ). I am actually surprised that was fixed and marked as important because the normal workbench behaviour is to open an editor in the currently active editor group. On top of that, the solution also does not seem right because what if I start in column 2 and I open a document in column 3 and then open the document from column 2 again. It opens in column 1?
I was surprised as well as that was my argument too :)
I could rebase that PR again (since its quite old) if you'd like, but it will still fail because of a test checking for
Well, we had this behaviour in place, extensions rely on it , and we don't want to break them. That's why this is tricky The solution is to use column 1 if not specified, no column-math happens:
Change:
# Licensed under the MIT License. See License.txt in the project root for license information. # If root, ensure that --user-data-dir is specified <ins> ARGS=$@ </ins> if [ "$(id -u)" = "0" ]; then while test $# -gt 0 do

Discussion:
As per, issue (closed), the command line arguments such as -h, should work with the current version of VS Code. But does not work as expected in normal ubuntu installation. Binary being used: /usr/bin/code -/usr/share/code/bin/code VSCode Version: Version 1.7.1 Commit Date 2016-11-03T13:46:46.244Z Shell 1.3.8 Renderer 52.0.2743.82 Node 6.5.0 OS Version: Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial Steps to Reproduce: code --user-data-dir=/ws/linux/config/vscode/ code --user-data-dir=/ws/linux/config/vscode/ --help code --user-data-dir=/ws/linux/config/vscode/ /var/logs None of the above shows any help or open path as expected.
Updates: After a short digging around, either the main executable at is ignoring other arguments, including --user-data-dir when is present. Or is supressing or not using the other args. When the bash startup script, is used, there is no effect of arguments including path to open as well as other args like --help. The user-data-dir is not created when is passed. Whereas, when the main executable () is used, it looks like the arguments are passed and processed correctly. path to open, --new-window, -r are working as expected. But i guess the absence of , is causing causing the writing back to starting shell fail. Following errors are shown when using main executable.
Strange. I just tried, but failed to reproduce. We'd need to debug the CLI code on your machine. Any chance that it's a VM you could send us?
Not a vm. But if there are switches or edits that i can do to enable trace, i can run with trace on and share the output. I also tried and used the version, same problem. Any chances that there might be a conflict with existing electron installation ?
Interesting. Could be. Try the insiders version, since it's a completely separate product:
I think i found the root cause, can you share your startup script, may be we are using different version that it is working on your end.

The script is shifting and throwing away all args when used as root to check --user-data-dir. Just submitted a pull request with changes that retains and passes the commandline args.
Great to know. Moving this to he should know the details of that script. Great work, thanks for the effort!
Fixed in
Verified: ignores . does not ignore it.
Change:
} this.selectElement.selectedIndex = this.selected; <ins> if (!!this.options[this.selected] && !!this.options[this.selected].text) { this.selectElement.title = this.options[this.selected].text; } </ins> } public setAriaLabel(label: string): void {

Discussion:
DEBUG selectBox, when hover over, can't see title. Checked with latest insider build, has the same issue. While in version ! There is title ! May be caused be
do you have time to look into this?
do you see this for other dropdowns as well. For example the terminal dropdown, or the output channel name dropdown?
Terminal dropdown has no title either.
Ok, so it is a general select box issue. Let's see if has time to look into this
Absolutely. I've been a bit awol... Will look at this tomorrow.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Change:
const terminalName = args.title || nls.localize('debug.terminal.title', "Debug Process"); <del> const termKey = createKeyForShell(shell, shellArgs, args); let terminal = await this._integratedTerminalInstances.checkout(termKey, terminalName, true); </del> <ins> const shellConfig = JSON.stringify({ shell, shellArgs }); let terminal = await this._integratedTerminalInstances.checkout(shellConfig, terminalName); </ins> let cwdForPrepareCommand: string | undefined; let giveShellTimeToInitialize = false;

Discussion:
See The change that caused this was a standalone fix for a relatively minor bug, so I will back it out for now.
I'm able to debug a JS file on macOS now with nvm and a launch configuration that contains .
Just a FYI - I don't use nvm but experienced this issue. The recent update fixed it for me, thanks!!