jiebi/CodeConvo huggingface dataset:
Code change:
If you return in a completion item, the property is when calling through . Setup: Test code: Output is: Full repro project is here:
It looks like the conversion is missing. The doc states that additionalTextEdits should not overlap with the main edit range or each other, should that be checked or is that done when the edits are carried out? Adding this: ! works, unless the range intersections need to be checked.
No checks required - this is already the way back from the UX and check should have been carried out already

Related discussion:
text: result.range = editorRange.Range.isIRange(suggestion.range) ? Range.to(suggestion.range) : undefined; result.range2 = editorRange.Range.isIRange(suggestion.range) ? undefined : { inserting: Range.to(suggestion.range.insert), replacing: Range.to(suggestion.range.replace) }; result.keepWhitespace = typeof suggestion.insertTextRules === 'undefined' ? false : Boolean(suggestion.insertTextRules & modes.CompletionItemInsertTextRule.KeepWhitespace); <del> // 'inserText'-logic </del> <ins> // 'insertText'-logic </ins> if (typeof suggestion.insertTextRules !== 'undefined' && suggestion.insertTextRules & modes.CompletionItemInsertTextRule.InsertAsSnippet) { result.insertText = new types.SnippetString(suggestion.insertText); } else { result.insertText = suggestion.insertText; result.textEdit = result.range instanceof types.Range ? new types.TextEdit(result.range, result.insertText) : undefined; } <del> // TODO additionalEdits, command </del> <ins> if (suggestion.additionalTextEdits && suggestion.additionalTextEdits.length > 0) { result.additionalTextEdits = suggestion.additionalTextEdits.map(e => TextEdit.to(e as modes.TextEdit)); } result.command = converter && suggestion.command ? converter.fromInternal(suggestion.command) : undefined; </ins> return result; }
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Currently, when a debugger is executed (ie by hitting F5), a terminal is opened and the debugger is executed as a command. This command can get pretty long as it also changes to the working directory and sets some environment variables. Running the Python debugger in a simple project with only one file runs a command which is 243 characters long. This, however, means that these commands which are not meant to be run by the user but are instead run automatically are still included in the user's shell history file by default. I propose changing the command generation function to include a space at the very beginning - on many shells across various distros, is set to not add commands to history if they start with a space character. This also gives some control to the user whether they'd like for the debugger commands to be stored in history or not.
If you were wondering why someone might want this, I like that the history is there. All the time I go to my command line and use up arrow enter to rerun the last auto generated command. I've also gone through the history a bunch to rerun previous auto generated commands too.
Aye, this is why I opted for simply adding a space instead of something more aggressive such as - the shell is still in control whether to preserve history or not with . EDIT: Also, in my shell, commands which were run with a space can still be reached by pressing the up key in the active session, but I'm not sure this is the case in other shells.
This works for the integrated terminal, but I noticed the external terminal doesn't get the space on OSX !
On MacOS the leading space character seems to get dropped in the Applescript that talks to the Terminal application. So the feature at hand only works for the integrated terminal for now. I've created a for the external terminal. Since has verified that the fix works for the integrated terminal, I'm adding the "verified" label.

Related discussion:
text: } let quote: (s: string) => string; <del> let command = ''; </del> <ins> // begin command with a space to avoid polluting shell history let command = ' '; </ins> switch (shellType) {
Code change:
Right now when a breakpoint is hit, the function in is called, and it in turn calls . The logic of is that it shows the wanted element at the very bottom of the scroll view. What this means is that in the Call Stack view, we'll only see the thread that hit the breakpoint and the first frame at the very bottom -- Ideally I think we want to show this at the top, so that we can see the whole stack trace, not just the first frame.
try it out in VS Code insiders from Friday and let us know if it behaves good for you so we add a verified label here. Thanks
did you get a chance to give this a spin?
sorry for the late reply. I tested it on the latest Insiders Build and it works as expected -- on breakpoint, the stack view shows the current thread in the middle if there are multiple threads in the program and the behavior is not changed compared to the previous version if there are fewer threads.
Also another question for you I can see that you guys (i.e. the VSCode team at Microsoft) are working heavily on Debugging UX improvements and our teams at Facebook could also suggest a few improvements we could benefit from. What is the process on picking the improvements to work on? Is it only done via feature requests? If so, how do you pick and prioritize the requests?
Thanks for coming back, adding verified label. For suggestions on improvments please create new feature requests. Feel free to ping me on them. Thanks

Related discussion:
text: this.ignoreSelectionChangedEvent = true; try { this.tree.setSelection([element]); <del> this.tree.reveal(element); </del> <ins> // If the element is outside of the screen bounds, // position it in the middle if (this.tree.getRelativeTop(element) === null) { this.tree.reveal(element, 0.5); } else { this.tree.reveal(element); } </ins> } catch (e) { } finally { this.ignoreSelectionChangedEvent = false;
Code change:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

Related discussion:
text: // Create directories as needed for (let i = directoriesToCreate.length - 1; i >= 0; i--) { directory = joinPath(directory, directoriesToCreate[i]); <del> await provider.mkdir(directory); </del> <ins> try { await provider.mkdir(directory); } catch (error) { if (toFileSystemProviderErrorCode(error) !== FileSystemProviderErrorCode.FileExists) { // For mkdirp() we tolerate that the mkdir() call fails // in case the folder already exists. This follows node.js // own implementation of fs.mkdir({ recursive: true }) and // reduces the chances of race conditions leading to errors // if multiple calls try to create the same folders // As such, we only throw an error here if it is other than // the fact that the file already exists. // (see also https://github.com/microsoft/vscode/issues/89834) throw error; } } </ins> } }
Code change:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

Related discussion:
text: import { NullLogService } from 'vs/platform/log/common/log'; import { isLinux, isWindows } from 'vs/base/common/platform'; import { DisposableStore } from 'vs/base/common/lifecycle'; <del> import { isEqual } from 'vs/base/common/resources'; </del> <ins> import { isEqual, joinPath } from 'vs/base/common/resources'; </ins> import { VSBuffer, VSBufferReadable, streamToBufferReadableStream, VSBufferReadableStream, bufferToReadable, bufferToStream, streamToBuffer } from 'vs/base/common/buffer'; import { find } from 'vs/base/common/arrays';
Code change:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

Related discussion:
text: assert.ok(!error); }); <ins> test('writeFile - no error when writing to same non-existing folder multiple times different new files', async () => { const newFolder = URI.file(join(testDir, 'some', 'new', 'folder')); const file1 = joinPath(newFolder, 'file-1'); const file2 = joinPath(newFolder, 'file-2'); const file3 = joinPath(newFolder, 'file-3'); // this essentially verifies that the mkdirp logic implemented // in the file service is able to receive multiple requests for // the same folder and will not throw errors if another racing // call succeeded first. const newContent = 'Updates to the small file'; await Promise.all([ service.writeFile(file1, VSBuffer.fromString(newContent)), service.writeFile(file2, VSBuffer.fromString(newContent)), service.writeFile(file3, VSBuffer.fromString(newContent)) ]); assert.ok(service.exists(file1)); assert.ok(service.exists(file2)); assert.ok(service.exists(file3)); }); test('writeFile - error when writing to folder that is a file', async () => { const existingFile = URI.file(join(testDir, 'my-file')); await service.createFile(existingFile); const newFile = joinPath(existingFile, 'file-1'); let error; const newContent = 'Updates to the small file'; try { await service.writeFile(newFile, VSBuffer.fromString(newContent)); } catch (e) { error = e; } assert.ok(error); }); </ins> const runWatchTests = isLinux; (runWatchTests ? test : test.skip)('watch - file', done => {
Code change:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

Related discussion:
text: await app.workbench.editors.newUntitledFile(); const untitled = 'Untitled-1'; <del> const textToTypeInUntitled = 'Hello, Untitled Code'; </del> <ins> const textToTypeInUntitled = untitled; </ins> await app.workbench.editor.waitForTypeInEditor(untitled, textToTypeInUntitled); const readmeMd = 'readme.md';
Code change:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

Related discussion:
text: await stableApp.workbench.editors.newUntitledFile(); const untitled = 'Untitled-1'; <del> const textToTypeInUntitled = 'Hello, Untitled Code'; </del> <ins> const textToTypeInUntitled = untitled; </ins> await stableApp.workbench.editor.waitForTypeInEditor(untitled, textToTypeInUntitled); const readmeMd = 'readme.md';
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: } //#endregion <ins> //#region https://github.com/microsoft/vscode/issues/90517 export interface FileSystemError { /** * A code that identifies this error. * * Possible values are names of errors, like [`FileNotFound`](#FileSystemError.FileNotFound), * or `undefined` for an unspecified error. */ readonly code?: string; } ////#endregion </ins> }
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: } // file system error <del> throw new FileSystemError(err.message, err.name as files.FileSystemProviderErrorCode); </del> <ins> switch (err.name) { case files.FileSystemProviderErrorCode.FileExists: throw FileSystemError.FileExists(err.message); case files.FileSystemProviderErrorCode.FileNotFound: throw FileSystemError.FileNotFound(err.message); case files.FileSystemProviderErrorCode.FileNotADirectory: throw FileSystemError.FileNotADirectory(err.message); case files.FileSystemProviderErrorCode.FileIsADirectory: throw FileSystemError.FileIsADirectory(err.message); case files.FileSystemProviderErrorCode.NoPermissions: throw FileSystemError.NoPermissions(err.message); case files.FileSystemProviderErrorCode.Unavailable: throw FileSystemError.Unavailable(err.message); default: throw new FileSystemError(err.message, err.name as files.FileSystemProviderErrorCode); } </ins> } }
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: return new FileSystemError(messageOrUri, FileSystemProviderErrorCode.Unavailable, FileSystemError.Unavailable); } <ins> readonly code?: string; </ins> constructor(uriOrMessage?: string | URI, code: FileSystemProviderErrorCode = FileSystemProviderErrorCode.Unknown, terminator?: Function) { super(URI.isUri(uriOrMessage) ? uriOrMessage.toString(true) : uriOrMessage); <ins> this.code = terminator?.name; </ins> // mark the error as file system provider error so that // we can extract the error code on the receiving side markAsFileSystemProviderError(this, code);
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: *--------------------------------------------------------------------------------------------*/ import { URI } from 'vs/base/common/uri'; <del> import { IFileSystemProviderWithFileReadWriteCapability, FileSystemProviderCapabilities, IFileChange, IWatchOptions, IStat, FileOverwriteOptions, FileType, FileDeleteOptions, FileWriteOptions, FileChangeType, FileSystemProviderErrorCode } from 'vs/platform/files/common/files'; </del> <ins> import { IFileSystemProviderWithFileReadWriteCapability, FileSystemProviderCapabilities, IFileChange, IWatchOptions, IStat, FileOverwriteOptions, FileType, FileDeleteOptions, FileWriteOptions, FileChangeType } from 'vs/platform/files/common/files'; </ins> import { Disposable, IDisposable } from 'vs/base/common/lifecycle'; import { Event, Emitter } from 'vs/base/common/event'; import { VSBuffer } from 'vs/base/common/buffer';
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: size: 0 }; } <del> return Promise.reject(new FileSystemError(resource, FileSystemProviderErrorCode.FileNotFound)); </del> <ins> return Promise.reject(FileSystemError.FileNotFound(resource)); </ins> } async readdir(resource: URI): Promise<[string, FileType][]> { const hasKey = await this.hasKey(resource.path); if (hasKey) { <del> return Promise.reject(new FileSystemError(resource, FileSystemProviderErrorCode.FileNotADirectory)); </del> <ins> return Promise.reject(FileSystemError.FileNotADirectory(resource)); </ins> } const keys = await this.getAllKeys(); const files: Map<string, [string, FileType]> = new Map<string, [string, FileType]>();
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: async readFile(resource: URI): Promise<Uint8Array> { const hasKey = await this.hasKey(resource.path); if (!hasKey) { <del> return Promise.reject(new FileSystemError(resource, FileSystemProviderErrorCode.FileNotFound)); </del> <ins> return Promise.reject(FileSystemError.FileNotFound(resource)); </ins> } const value = await this.getValue(resource.path); return VSBuffer.fromString(value).buffer;
Code change:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help

Related discussion:
text: if (!hasKey) { const files = await this.readdir(resource); if (files.length) { <del> return Promise.reject(new FileSystemError(resource, FileSystemProviderErrorCode.FileIsADirectory)); </del> <ins> return Promise.reject(FileSystemError.FileIsADirectory(resource)); </ins> } } await this.setValue(resource.path, VSBuffer.wrap(content).toString());
Code change:
Refs: A text document can be readonly if it's underlying file system provider is readonly. I am not sure how a custom editor implementor can figure this out and provide the correct experience.
Could we add a property to ? Does VS Code internally already know if a given textDocument is read only?
We basically ask the file system provider for the resource of the document for being readonly or not. That should be doable.

Related discussion:
text: }): Disposable; } //#endregion <ins> //#region export interface FileSystem { /** * Check if a given file system supports writing files. * * Keep in mind that just because a file system supports writing, that does * not mean that writes will always succeed. There may be permissions issues * or other errors that prevent writing a file. * * @param scheme The scheme of the filesystem, for example `file` or `git`. * * @return `true` if the file system supports writing, `false` if it does not * support writing (i.e. it is readonly), and `undefined` if VS Code does not * know about the filesystem. */ isWritableFileSystem(scheme: string): boolean | undefined; } //#endregion </ins> }