jiebi/CodeConvo huggingface dataset:
Change:
* null means the process was killed as a result of the ITerminalInstance being disposed. */ onExit(listener: (exitCode: number) => void): void; <ins> /** * Immediately kills the terminal's current pty process and launches a new one to replace it. * * @param shell The new launch configuration. */ reuseTerminal(shell?: IShellLaunchConfig): void; </ins> }

Discussion:
From
For January we decided to keep the task in the core. So there is no need to make this 'public' API now. May be it would be good to first experiment a little with the new API.
just to make sure, were you thinking of using a prompt (press any key to close) that can be reused? Or a terminal that executes something, the pty process dies and just sits there ("dead") until another task command is sent?
I would like to achieve the following: create a new terminal and allow terminal reuse (could be an additional option) without actually running a terminal right away (if necessary we could run it as well) run a command in the terminal. This will create the actual shell process. Usually the shell would be started with /c receive an exit event when the shell exists reuse the terminal to run another command in the terminal which creates a new shell process. Use case if for a build task: if the user runs the build tasks 3 times in a row I would like to have one terminal (e.g. on entry in the drop down in the terminal pane) which contains the output of all three task runs.
I have one additional question. Does the terminal require to run a shell or would the terminal be able to run any other arbitrary process (for example a ).
I got it working to run an arbitrary program. Only drawback is that I needed to specify the full path to the program (e.g. ). Any idea why this is the case?
do you mean the shell path you're using is and it's not working like that? I guess the resolution stuff is contained within , I would think it would probably be safest to always wrap the command within or . Wrapping the command means the process will die when it finishes so I don't see a downside?
the only problem is argument passing with spaces contained. If you call node directly then you pass the args as a string[]. If you call the for example you need to construct a single string with proper arg quoting to ensure everything works when for example the command to call contains spaces. And you save a process :-)
could this be useful for Python terminal execution?
Change:
import { PANEL_BACKGROUND, SIDE_BAR_BACKGROUND } from 'vs/workbench/common/theme'; import { IMenu, IMenuService, MenuId, MenuItemAction } from 'vs/platform/actions/common/actions'; import { ITerminalProfile, TERMINAL_COMMAND_ID } from 'vs/workbench/contrib/terminal/common/terminal'; <del> import { BaseActionViewItem, SelectActionViewItem } from 'vs/base/browser/ui/actionbar/actionViewItems'; </del> <ins> import { ActionViewItem, BaseActionViewItem, SelectActionViewItem } from 'vs/base/browser/ui/actionbar/actionViewItems'; </ins> import { ITerminalContributionService } from 'vs/workbench/contrib/terminal/common/terminalExtensionPoints'; import { attachSelectBoxStyler, attachStylerCallback } from 'vs/platform/theme/common/styler'; import { selectBorder } from 'vs/platform/theme/common/colorRegistry';

Discussion:
For reuse by other code areas
Also polish styling including a hover over the joint buttons
Mockup: !
Fixed in
Change:
resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.1.3.tgz#fb738703ae8d2f9fe900c33836ddebee8b97f23e" integrity sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ== <ins> fsevents@~2.3.1: version "2.3.1" resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.3.1.tgz#b209ab14c61012636c8863507edf7fb68cc54e9f" integrity sha512-YR47Eg4hChJGAB1O3yEAOkGO+rlzutoICGqGo9EZ4lKWokzZRSyIW1QmTzqjtw8MJdj9srP869CuWw/hyzSiBw== </ins> fstream@^1.0.2: version "1.0.11" resolved "https://registry.yarnpkg.com/fstream/-/fstream-1.0.11.tgz#5c1fb1f117477114f0632a0eb4b71b3cb0fd3171"

Discussion:
Steps to Reproduce: on Apple SI a folder in devtools:
Related failing unit test:
Chokidar v3.5.0 was just released that takes in fsevents universal build , we can update to it.
yep this required compiling fsevents as universal binary
Change:
this._safeSetOption('rightClickSelectsWord', config.rightClickBehavior === 'selectWord'); this._safeSetOption('wordSeparator', config.wordSeparators); const suggestedRendererType = this._storageService.get(SUGGESTED_RENDERER_TYPE, StorageScope.GLOBAL); <del> if ((suggestedRendererType === 'auto' && config.rendererType === 'auto') || config.rendererType === 'experimentalWebgl') { </del> <ins> if ((config.rendererType === 'auto' && suggestedRendererType === undefined) || config.rendererType === 'experimentalWebgl') { </ins> this._enableWebglRenderer(); } else { this._disposeOfWebglRenderer(); <del> this._safeSetOption('rendererType', config.rendererType === 'auto' ? 'canvas' : config.rendererType); </del> <ins> this._safeSetOption('rendererType', (config.rendererType === 'auto' && suggestedRendererType === 'dom') ? 'dom' : (config.rendererType === 'dom' ? 'dom' : 'canvas')); </ins> } this._refreshEnvironmentVariableInfoWidgetState(this._processManager.environmentVariableInfo); }

Discussion:
Part of We should also improve the fallback logic to do this: Try webgl If it threw an exception, try canvas If frame rendering averages 50ms (existing detection), use DOM We will keep the canvas renderer around for now mainly because Safari doesn't support webgl2 and can evaluate again at a later date.
It looks like canvas is still the default for me -- the is present unless I explicitly enable experimentalWebgl. I don't see any notifications of errors that could be causing it.
Change:
async getBranchBase(ref: string): Promise<Branch | undefined> { const branch = await this.getBranch(ref); <del> const branchMergeBaseConfigKey = `branch.${branch.name}.vscode-merge-base`; </del> <ins> const branchUpstream = await this.getUpstreamBranch(branch); </ins> <del> // Upstream if (branch.upstream) { return await this.getBranch(`refs/remotes/${branch.upstream.remote}/${branch.upstream.name}`); </del> <ins> if (branchUpstream) { return branchUpstream; </ins> } // Git config <ins> const mergeBaseConfigKey = `branch.${branch.name}.vscode-merge-base`; </ins> try { <del> const mergeBase = await this.getConfig(branchMergeBaseConfigKey); if (mergeBase !== '') { const mergeBaseBranch = await this.getBranch(mergeBase); return mergeBaseBranch; </del> <ins> const mergeBase = await this.getConfig(mergeBaseConfigKey); const branchFromConfig = mergeBase !== '' ? await this.getBranch(mergeBase) : undefined; if (branchFromConfig) { return branchFromConfig; </ins> } } catch (err) { } // Reflog const branchFromReflog = await this.getBranchBaseFromReflog(ref); <del> if (branchFromReflog) { await this.setConfig(branchMergeBaseConfigKey, branchFromReflog.name!); return branchFromReflog; </del> <ins> const branchFromReflogUpstream = branchFromReflog ? await this.getUpstreamBranch(branchFromReflog) : undefined; if (branchFromReflogUpstream) { await this.setConfig(mergeBaseConfigKey, `${branchFromReflogUpstream.remote}/${branchFromReflogUpstream.name}`); return branchFromReflogUpstream; </ins> } // Default branch const defaultBranch = await this.getDefaultBranch(); if (defaultBranch) { <del> await this.setConfig(branchMergeBaseConfigKey, defaultBranch.name!); </del> <ins> await this.setConfig(mergeBaseConfigKey, `${defaultBranch.remote}/${defaultBranch.name}`); </ins> return defaultBranch; }

Discussion:
Testing Start from , on a repo: The git extension will associate as the most likely candidate for 's base. But since does have an upstream, , which, at the point was created, was pointing to the same commit as itself... wouldn't be a better base candidate instead?
I think that this makes sense to me however would you favour the remote branch (origin/foo) just because it points to the same commit as when was created or should it be a general rule that if a remote is present, we would favour it?
Will mark this and look out for additional feedback.
Though more about this and since we are adding and actions to the incoming node, it does make sense for it to be an upstream branch. Marking the issue as "bug" so that it gets verified during endgame.
Change:
flex-shrink: 0; } <ins> .monaco-workbench .part > .title > .title-actions .start-debug-action-item .codicon-debug-start { width: 18px; height: 21px; padding-left: 2px; } </ins> .monaco-workbench .monaco-action-bar .start-debug-action-item .configuration .monaco-select-box { border: none; margin-top: 0px;

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. --The debug button is really small. Can it be big? The drop down menu as well as the other debug buttons could be on a toolbar under the debug title and this could be much bigger and easier.  Or the play button could be bigger button like the 'commit' button: <img width="422" alt="Screen Shot 2022-10-10 at 8 00 21 PM" src="https://user-"
The clickable area of that button is 16x20. Most menu buttons are 22x22. I haven't had an issue with this but could it be a ux or accessibility issue? Here's what it would look like if it were 22px wide <img width="312" alt="image" src="https://user-"The big button is an interesting idea but I'm not a big fan of that button. I find it really aggressive and loud and I disable it in scm.
Making it 22px makes sense. I think it should be consistent with the other button sizes across the workbench.
thanks a lot :) it has been the fastest fix on history :))
Did slightly less than the full 22px - due to the border and the background color, I think that feels too wide. But this should help.
Change:
case 'workspaceRootFolderName': case 'workspaceFolderBasename': <del> return paths.basename(this.fsPath(getFolderUri(VariableKind.WorkspaceFolderBasename))); </del> <ins> return normalizeDriveLetter(paths.basename(this.fsPath(getFolderUri(VariableKind.WorkspaceFolderBasename)))); </ins> case 'userHome': { if (environment.userHome) {

Discussion:
Sorry for asking questions in the issue tracker. Reading I originally assumed vscode was normalizing the drive letter casing. uses upper case drive letter. However, I noticed that variables like , , on my Windows are resolved to file paths with lower case drive name, e.g. . is not consistently applied from this part of the code but I am not sure if they are supposed to be handled elsewhere. Is there a documentation on what is normalized or not normalized, and if normalized, it will be upper case or lower case. (It's not clear to me what's the final conclusion of length discussions like ) And, for debugging requests, can we assume all requests that carry the absolute file paths use normalized file path?
Another fun finding is, normalizes the drive casing to lower-case As a result, our extension ends up normalizing a path to use upper case drive letter, converting it to which uses lower-case in fsPath, and at some point, translating fsPath to upper case, ...
I think the conclusion is that we should try to be consistent with URIs coming from vscode, but remember that we can't control the whole environment- e.g. the runtime may do something different than URIs that come from DAP. I don't know why would have a different drive letter case than . Seems wrong. Do you know anything about that
I think it's just an oversight that the drive letter isn't always normalized. I'm happy to make this change during the next debt week so that it has plenty of time in insiders for folks to notice if it breaks anything.
Change:
assert.throws(() => (env as any).appName = '234'); assert.throws(() => (env as any).machineId = '234'); assert.throws(() => (env as any).sessionId = '234'); <ins> assert.throws(() => (env as any).shell = '234'); </ins> }); test('env.remoteName', function () {

Discussion:
Provided the Python extension uses the API and it works as expected (), we should finalize it in July.
To verify just do a quick test that it seems to be working as expected on any platform, a more thorough test was done in the June milestone.
Change:
const symbolsProviderRegistration = vscode.languages.registerDocumentSymbolProvider({ language: 'markdown' }, symbolsProvider); context.subscriptions.push(contentProviderRegistration, symbolsProviderRegistration); <ins> context.subscriptions.push(vscode.languages.registerDocumentLinkProvider('markdown', new DocumentLinkProvider())); </ins> context.subscriptions.push(vscode.commands.registerCommand('markdown.showPreview', showPreview)); context.subscriptions.push(vscode.commands.registerCommand('markdown.showPreviewToSide', uri => showPreview(uri, true))); context.subscriptions.push(vscode.commands.registerCommand('markdown.showSource', showSource));

Discussion:
It is possible to follow local links for the markdown? For example, I have two splits for a markdown file: one for editing, and the other one for previewing. If I have a local link . When clicking this link in the preview split, is it possible for both the two splits automatically switch to Further, is it possible to sync two scroll bars for the preview split and the edit split?
That would be nice for docs written in Markdown.
VSCODE 1.7.1 on Windown 8.1 Currently the links are working in the preview Pane, but can not be followed from editor with like it is possible for normal links !
I just checked in a fix to support identifying links in the markdown editor . will tackle clicking local links in the preview itself. Please give it a try in the next insiders build
Tried the insiders build, works as expected. Great work, thanks Update: Spaces in the file names are not recognized
Change:
testLink('c:/a/long/path'); testLink('c:alongpath'); testLink('c:mixed/slashpath'); <ins> testLink('a/relative/path'); </ins> }); test('Linux', () => {

Discussion:
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.2 OS Version: Mac OSX (10.11.6) Steps to Reproduce: VS Code integrated terminal a relative path (eg. ) Description: Let's say you have a build system that outputs a stack trace on a build error or failed test. If this was run from the integrated terminal, the file paths in the output should be included as clickable links which can be clicked to open the file in VSCode. However, this only works if the path is either an absolute path (e.g. ) or a relative path that begins with "./". Many build systems and tools output file paths relative to the directory the command was run, without the leading "./", Karma for example. So the output would be something like: , not . The first is not matched by VSCode as an openable path, but the second is. I believe that what is determined to be a path comes from the Regex in "" Is there a reason why relative paths of this form (e.g. no leading "./") are not included?
The reason was because until 1.11 links aren't validated so there would be heaps of false positives. Performance was also a factor but it shouldn't impact that much really now that I think about it. Now that links are validated maybe we should be more lenient when linkifying.
I'll assign this to April but if someone wants to do a PR before then you're welcome. You will need to: Modify the regex to allow paths that are not qualified with , , etc. Make sure that the new path matcher does not conflict with previously matched links and does not create links with adjacent characters. Eg. we want to avoid this:
Nice. I'll write a PR...
That would be awesome :+1:
Fixed in
Change:
if (editorWidget) { // Ensure that the editor widget is binded. If if is, then this should return immediately. // Otherwise, it will bind the widget. <del> await elemParent.bindNotebookEditorWidget(editorWidget); </del> <ins> elemParent.bindNotebookEditorWidget(editorWidget); </ins> await elemParent.updateMatchesForEditorWidget(); const matchIndex = oldParentMatches.findIndex(e => e.id() === element.id());

Discussion:
some text in an editor +shift+f and search for that text screen reader will report that the result is on a column that is actual+2 !
pretty sure this is by design, but can answer that
Thinking about it, it seems to not make much sense to start at 2 (although I see this behavior in areas outside of notebooks). do you see why this should be design? If not, I can go ahead and try to make the columns start at 1 like it does in the editor.
Yeah that sounds good to me thanks

repro: in settings notebook search filter to look at outputs all editors for something that only appears in outputs on the result and wait for the results to convert to rich notebook results list focus has shifted !
Hi - I'm attempting to replicate this bug, but cannot generate the output from a notebook because my build (Code - OSS Dev) crashes when I select a kernel for my notebook with the message . I am getting the extension form How were you able to get the Jupyter notebook running in your build?
I installed the Jupyter extension via the vsix that is in the marketplace install page.
Thank you for the reply! I still run into the same error after installing the extensions from vsix when I select the kernel. Console output
Hmm, I'm not sure why this would happen. Since this is not really related to this issue directly, could you file a new issue?
I believe the issue is related to this line in folderMatch.allDownstreamFileMatches() is returning a set of notebook files that excludes the parent file of the current selection.
Change:
import { IJSONSchema } from 'vs/base/common/jsonSchema'; import { Disposable } from 'vs/base/common/lifecycle'; import { Emitter } from 'vs/base/common/event'; <del> import { ConfigurationScope, EditPresentationTypes, Extensions, IConfigurationRegistry } from 'vs/platform/configuration/common/configurationRegistry'; </del> <ins> import { ConfigurationScope, EditPresentationTypes, Extensions, IConfigurationRegistry, IExtensionInfo } from 'vs/platform/configuration/common/configurationRegistry'; </ins> import { ILanguageService } from 'vs/editor/common/languages/language'; import { Registry } from 'vs/platform/registry/common/platform';

Discussion:
On Insiders, for in the Settings editor. an HTML language filter to that setting. A default override indicator shows up for the setting that indicates that the default setting value of the extension has been overridden by the HTML Languages extension. remove the language filter from the search query in the search bar. :bug: The default override indicator still remains, even though we are back to the non-language-specific scope.
Change:
this._onDidSelect.fire({ index: this.selectElement.selectedIndex, selected: this.options[this.selected].text }); <ins> if (!!this.options[this.selected] && !!this.options[this.selected].text) { this.selectElement.title = this.options[this.selected].text; } </ins> } this.hideSelectDropDown(true);

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:
this.options.getApiFor(oldActual).listener = undefined; internal.actual = actual; <ins> internal.resolveBarrier = undefined; </ins> internal.expand = TestItemExpandState.NotExpandable; // updated by `connectItemAndChildren` if (update) {

Discussion:
My extension's has a that replaces all root items whenever it is called. It calls the same function that creates the items upon extension activation. After the is run, I've verified that the correct root items have been created with set to . However, when the user tries to expand the item, the is not called on that item and no children are created. This simple extension demonstrates the bug: Steps to Reproduce: the extension above. It should immediately activate after the window refresh. the text explorer and observe the root item. Expand it to reveal two children. the Output channel to see that the resolve handler was called. the refresh icon and verify that "Refreshing" was written to the Output channel. to expand the new root. Verify that the resolve handler was never called. VS Code Version: 1.87.2
Thanks for triaging this Do you anticipate this being resolved before the next release? If not, do you have a recommended workaround I should try to implement in my extension?
A fix for this would be highly appreciated. This bug is a major annoyance for my daily work I started creating a new issue for , but googled first and found this one instead I even "fixed" the issue by adding the following line into the refreshHandler Like so: testController.refreshHandler = () ={ replaceRootTestItems(testController); ((item) =testController.resolveHandler(item)); };
Thanks for the tip I'll give that a try as a workaround.
<!-- 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!
Thanks for fixing this!
Change:
/** * Whether symlinks should be followed while searching. <del> * See the vscode setting `"search.followSymlinks"`. </del> <ins> * Defaults to the value for `search.followSymlinks` in settings. * For more info, see the setting listed above. </ins> */ followSymlinks?: boolean; /** * If set to true, the `filePattern` arg will be fuzzy-searched instead of glob-searched. <del> * If `filePattern` is a `GlobPattern`, then the fuzzy search will act on the `pattern` of the `RelativePattern` </del> <ins> * If `filePattern` is a {@link RelativePattern relative pattern}, then the fuzzy search will act on the `pattern` of the {@link RelativePattern RelativePattern} </ins> */ fuzzy?: boolean; }

Discussion:
Testing It is not clear what is the default value.
Good point. The default value is the value in settings.
Change:
import { IFileService } from 'vs/platform/files/common/files'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { ILabelService } from 'vs/platform/label/common/label'; <del> import { IEditorIdentifier, IResourceMergeEditorInput, isResourceMergeEditorInput, IUntypedEditorInput } from 'vs/workbench/common/editor'; </del> <ins> import { EditorInputCapabilities, IEditorIdentifier, IResourceMergeEditorInput, isResourceMergeEditorInput, IUntypedEditorInput } from 'vs/workbench/common/editor'; </ins> import { EditorInput, IEditorCloseHandler } from 'vs/workbench/common/editor/editorInput'; import { AbstractTextResourceEditorInput } from 'vs/workbench/common/editor/textResourceEditorInput'; import { EditorWorkerServiceDiffComputer } from 'vs/workbench/contrib/mergeEditor/browser/model/diffComputer';

Discussion:
Just came across this code that conditionally leaves zen mode when side by side or diff editors are opened: We probably want something similar when a merge editor is opened.
enable centered editor layout open a merge editor verify centered editor layout exits
Verified