jiebi/CodeConvo huggingface dataset:
Change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.1.3: version "19.1.3" resolved "https://registry.yarnpkg.com/electron/-/electron-19.1.3.tgz#90a2b6c3d738789d657477d87d1539f008be6536" integrity sha512-P2kfFc8UqVvPHE1w9qTZSPNpfOqd+CK34K3wBqJwokzYdVBLsVkbIoLxyByjJ/cU35WaeCL5bsI8kXALfPvebw== </del> <ins> electron@19.1.6: version "19.1.6" resolved "https://registry.yarnpkg.com/electron/-/electron-19.1.6.tgz#32443cd293d3d877cd3d224e45880e3fbf264e49" integrity sha512-bT6Mr7JbHbONpr/U7R47lwTkMUvuAyOfnoLlbDqvGocQyZCCN3JB436wtf2+r3/IpMEz3T+dHLweFDY5i2wuxw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Discussion:
As part of chromium a runtime feature called AutoDisableAccessibility and it works like this: We should try out this flag to see how it affects our accessibility detection on macOS.
thanks a lot for this. Just as a refresh, this only affects macOS? fyi this change might affect our telemetry numbers - since now we might auto disable accessibility when chrome decides it is actually not being needed.
I have enabled it for all OS since there is no downside. As part of this, I also redid the accessibility event that gets fired from the runtime to work well with this feature flag. So, in endgame it would be good to have test plan that ensures our accessibility detection continues works fine on all OS.
ok, I can create a test plan item for that today with complexity 3. fyi
Created test plan item Feel free to edit it if you think I did not cover some scenario. Thanks!
Change:
description = item.description; detail = item.detail; picked = item.picked; <ins> alwaysShow = item.shouldAlwaysShow; </ins> } pickItems.push({ label, description, handle, detail, <del> picked </del> <ins> picked, alwaysShow </ins> }); }

Discussion:
Problem The time you search for the branch and not find any, there are no other options to proceed. <img width="682" alt="screen shot 2018-09-15 at 11 06 09" src="https://user-"I as a developer would need to delete the search and then click on "create a new branch". Solution Keep "create a new branch" option always. <img width="656" alt="screen shot 2018-09-15 at 11 22 56" src="https://user-"
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.617 --- <!-- score: 0.587 --- <!-- score: 0.552 --- <!-- score: 0.547 --- <!-- score: 0.529 --<!-- potentialduplicatescomment --
Is this supported from an extension? Eg: keep an option always visible.
Dang, just noticed that you already submitted a PR to address this. Closed my PR, feel free to grab the integration test I if you want
since my PR is merged already, feel free to create a PR with tests :)
I a PR to add tests and also fix a small bug (when explicitly settings items on a the field was not properly propagated). Additional thoughts I had (should open another issue for discussion?): In my opinion, items that should always be shown shouldn't display search highlights. The highlights are possibly redundant and IMO it would look more elegant without I feel like after accepting the option, the input text should be preserved. Would a PR to address this be accepted? Also, possibly should this behavior be exposed for user control? (i.e. similarly to a field, a field.)
:+1: Nah, sounds like a very good default value.
Change:
} // all empty -> replace this editor with a normal editor for result that.editorService.replaceEditors( <del> [{ editor: input, replacement: { resource: input.result }, forceReplaceDirty: true }], </del> <ins> [{ editor: input, replacement: { resource: input.result, options: { preserveFocus: true } }, forceReplaceDirty: true }], </ins> that.group ?? that.editorGroupService.activeGroup ); }

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/No <!-- 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.72.0-insider (user setup) Commit: Date: 2022-09-13T05:18:15.280Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Steps to Reproduce: attempting a merge, I did "git merge --abort" from the terminal in VS Code. the command completed, I had another git command to run so I started typing it, assuming focus was still in the terminal. I was surprised to see though that focus had shifted to the editor after the git merge --abort command and that instead of typing my command in the terminal, I ended up modifying the editor. I expected that focus would remain in the terminal after the git merge --abort command.
does this happen with any other git commands or only git merge --abort?
I also saw this when testing merge editor and think this is relevant only for merge editors.
I haven't done extensive testing of many git commands but git merge --abort is the only one I have seen so far that does this.
is this something that you could look into? Thanks!
likely because of the workaround for The merge editor detect the inputs (current, incoming, base) going empty and closes itself. I guess we don't tell the workbench to preserve focus then which happens somewhere
Upon inspection I now wonder if there is a way to replace editors (via ) while preserving focus?
Change:
this.updateButtons(this._foundMatch); return { content: e.message }; } <del> } </del> <ins> }, appendCaseSensitiveLabel: _options.appendCaseSensitiveLabel && _options.type === 'Terminal' ? this._getKeybinding(TerminalCommandId.ToggleFindCaseSensitive) : undefined, appendRegexLabel: _options.appendRegexLabel && _options.type === 'Terminal' ? this._getKeybinding(TerminalCommandId.ToggleFindRegex) : undefined, appendWholeWordsLabel: _options.appendWholeWordsLabel && _options.type === 'Terminal' ? this._getKeybinding(TerminalCommandId.ToggleFindWholeWord) : undefined </ins> }, contextKeyService, _options.showOptionButtons)); // Find History with update delayer

Discussion:
And instead pass in (or don't) a new option for the type
so the complexity here is that we can't reference the keybinding service within the super call to the constructor and need to do that to provide the options to the find input object that's read only.
the alternative would be to pass in the options from both the terminal view and terminal editor (redundant)
going to pass in an options object and handle the keybinding in simple find widget
Spent awhile on this, don't think we will get to it
Change:
} function createExtensionProfileDescription(profile: IExtensionTerminalProfile): string { <del> let description = `$(${ThemeIcon.isThemeIcon(profile.icon) ? profile.icon.id : profile.icon ? profile.icon : Codicon.terminal.id}) ${profile.title}n- extensionIdenfifier: ${profile.extensionIdentifier}`; </del> <ins> let description = `$(${ThemeIcon.isThemeIcon(profile.icon) ? profile.icon.id : profile.icon ? profile.icon : Codicon.terminal.id}) ${profile.title}n- extensionIdentifier: ${profile.extensionIdentifier}`; </ins> return description; }

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. --- VS Code Version: Latest/Master branch OS Version: All Steps to Reproduce: to settings the one for your OS (with the dropdown set to by default) over the last line (notice how it says instead of
<img width="866" alt="Screen Shot 2022-05-16 at 7 56 38 am" src="https://user-"
Change:
focus(): void { this._inlineChatWidget.focus(); } <del> focusResponse(): void { const responseElement = this._inlineChatWidget.domNode.querySelector(ChatElementSelectors.ResponseEditor) || this._inlineChatWidget.domNode.querySelector(ChatElementSelectors.ResponseMessage); if (responseElement instanceof HTMLElement) { responseElement.focus(); } } </del> hasFocus(): boolean { return this._inlineChatWidget.hasFocus(); }

Discussion:
Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list
Change:
override dispose(): void { this._onWillChangeModelListener?.dispose(); <ins> this._onDidChangeModelListener?.dispose(); </ins> this.disposePastResults(); this.disposeMatches(); this._rangeHighlightDecorations.dispose();

Discussion:
Type: <bBug</ba jupyter notebook, create a python cell the cell the notebook two earch results the notebook bug One of the search results goes away <img width="1179" alt="Screenshot 2023-04-25 at 11 09 04 AM" src="https://user-"Making any changes to the search term makes both search results show again VS Code version: Code - Insiders 1.78.0-insider (Universal) (, 2023-04-25T05:41:22.331Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
/* .foo { op.3 dn	{ */ <del> @ </del> <ins> bgc </ins> } bg `; return withRandomFileEditor(sassContents, '.scss', (_, doc) => {

Discussion:
Note: char disable tab after it with setting even with custom snippet the not trigger because char disable tab after it.
closedWith
Actually, reopening since I realized the extension isn't allowing the abbreviations outside of surrounding braces. the latest Emmet doesn't allow + in the expansions now, so you'd have to create custom snippets (with names that don't have +) to get that old behaviour back.
"+" Cheats| 1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- 16- 17- 18- 19- 20- 21- 22- 23-
I'm aware there were a lot of snippets with +. The Emmet documentation website is currently outdated. See and
Sorry I didn't know that.
Verifier: verify that in an empty stylesheet document (e.g. CSS), , , , and all have an Emmet suggestion showing up.
Change:
} set enabled(enabled: boolean) { <del> this.findInput.setEnabled(enabled); </del> <ins> // We can't disable the input box because it is still used for // navigating the list. Instead, we disable the list and the OK // so that nothing can be selected. // TODO: should this be what we do for all find inputs? Or maybe some _other_ API // on findInput to change it to readonly? this.findInput.inputBox.inputElement.toggleAttribute('readonly', !enabled); // TODO: styles of the quick pick need to be moved to the CSS instead of being in line // so things like this can be done in CSS // this.findInput.inputBox.inputElement.classList.toggle('disabled', !enabled); </ins> } set toggles(toggles: Toggle[] | undefined) {

Discussion:
enabled: <img width="662" alt="image" src="https://user-"disabled: <img width="683" alt="image" src="https://user-"The fix in asks the following follow up questions: "being disabled" be styled differently than "being enabled"? Right now they are rendered identically. the event of disablement, it looks like the only valid thing that can take focus is the entire quick pick container which asks the following questions: does it look right? is it accessible? what do you think?
What are the use cases for a disabled quick pick?
Yeah it's a good question... I'm not entirely sure. I think maybe when you have server-side validation... so: "Enter the name of the Azure Static Web App you want to create" type in 'foo' and hit Enter quick pick sets the property and the property to signal that the input is being processed got a result from slow API saying 'foo already exists'... surface that to the user and reenable input
Seems like we should be dimming the value text and setting the input use a attribute to start. I assume we're showing progress via a notification or some other indicator? <img width="581" alt="CleanShot 2022-12-06 at 10 53 05 src="https://user-"
Our azure extension friends are hitting this - the actual user issue for them is that focus is not preserved. So the quick pick shows up first as disabled, and then later they enable it (once API request comes back). And the focus is not there - so the user can not hit enter. Can we look into making sure that on quick pick enablement we pass focus into the input box (if the focus is already anywhere in the big quick pick element)? Please correct me if needed
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification: a new extension with this code in inside the callback of the hello world command F5 the Hello World command from the command palette The focus should still be in the input box (and not on the outer area like the screenshot above shows) and you should not be able to change the contents of the input box.
Change:
private readonly _onDidInitiateWorkspaceTrustRequest = new Emitter<WorkspaceTrustRequestOptions>(); readonly onDidInitiateWorkspaceTrustRequest = this._onDidInitiateWorkspaceTrustRequest.event; <ins> private readonly _onDidInitiateWorkspaceTrustRequestOnStartup = new Emitter<void>(); readonly onDidInitiateWorkspaceTrustRequestOnStartup = this._onDidInitiateWorkspaceTrustRequestOnStartup.event; </ins> constructor(private readonly _trusted: boolean) { } requestOpenUrisHandler = async (uris: URI[]) => {

Discussion:
I created a brand new VM and attached remote-ssh to it, then opened my folder on it. I clicked to trust the folder, then immediately after I was prompted by the terminal to trust the folder again. Every time I open a new folder thereafter I'm again double prompted for trust.
this is how we use the API, is promise for the original prompt not being shared with successive requests or something?
All callers of should be sharing the same promise. I will try to set up a repro today and see if I can reproduce the problem locally.
Here is what is happening: initial workspace trust modal dialog is being displayed there is another workspace trust dialog displayed due to the call the workspace will actually resolve the promise and in the background you can see the terminal is initiated The workspace trust request dialog is not being dismissed. I do have couple of ideas that I will discuss with
The fix will be available in Friday's Insiders release.
Change:
return new ContextKeyEqualsExpr(pieces[0].trim(), this._deserializeValue(pieces[1])); } <ins> if (serializedOne.indexOf('=~') >= 0) { let pieces = serializedOne.split('=~'); return new ContextKeyGlobExpr(pieces[0].trim(), this._deserializeValue(pieces[1])); } </ins> if (/^!s*/.test(serializedOne)) { return new ContextKeyNotExpr(serializedOne.substr(1).trim()); }

Discussion:
VSCode Version: 1.12.0 OS Version: MacOS Sierra 10.12.4 In , we'd like to be able to provide context menus for all gradle files. The current clause is limited to language types () or a single file name (). It would be helpful if there was support for glob pattern matching, as mentioned in
Hi, Any update on this?
I will push an additional change that expands this to support normal regular expressions instead of just glob-patterns. We figured that's more powerful and closer to ST
Will this be usable in matching any when clause value? Can you give an example?
You write , so will execute this . A sample from my dummy extensions (matches filenames ending in )
This is AWESOME! Should reduce the number of duplicate menu items I need to define
Slight update on this: The value must be enclosed in slashes, so . I have updated above sample
FYI: I tried to apply this feature to the "loaded script view" by following the entry in the release notes: ! But without much success. After looking into the test item and the corresponding feature item, I noticed that the latest syntax uses regular regexp syntax. I've taken the liberty to change the release notes to this: ! I did not attempt to clarify why actually matches "Docker files".
Hmm, I am writing a simple extension, and would like to copy any resourceName. It works without any when clause, but the menu item also shows up, when r-clicking inside the empty space. I would like to prevent it. Is there something like this ?
Ok I found . And its actually what I was looking for. But I did not found it in the docs, but code base.
Change:
'tags': ['accessibility'] }, [AccessibilityVoiceSettingId.SpeechLanguage]: { <del> 'markdownDescription': localize('voice.speechLanguage', "The language that voice speech recognition should recognize."), </del> <ins> 'markdownDescription': localize('voice.speechLanguage', "The language that voice speech recognition should recognize. Select `auto` to use the configured display language if possible. Note that not all display languages maybe supported by speech recognition"), </ins> 'type': 'string', 'enum': languagesSorted, <del> 'default': SpeechLanguageDefault, </del> <ins> 'default': 'auto', </ins> 'tags': ['accessibility'], 'enumDescriptions': languagesSorted.map(key => languages[key].name), 'enumItemLabels': languagesSorted.map(key => languages[key].name)

Discussion:
Fyi
Verification: install the pre-release version of speech extension: make sure is configured to (it should be by default) switch VS Code display language to another language that is supported by the speech extension such as german or portuguese start voice dictation in a text editor via "Start Dictation in Editor" verify you get prompted to install the related language pack for the display language you picked
Change:
description: editorDescriptor.id === currentlyOpenedEditorType ? nls.localize('openWithCurrentlyActive', "Currently Active") : undefined, <ins> detail: editorDescriptor.providerDisplayName, </ins> buttons: resourceExt ? [{ iconClass: 'codicon-settings-gear', tooltip: nls.localize('promptOpenWith.setDefaultTooltip', "Set as default editor for '{0}' files", resourceExt)

Discussion:
re This uses VS Code as hard-coded name, not the product name This reads a little cumbersome, why not "Text Editor" and as description (built-in) <img width="361" alt="Screenshot 2020-04-03 at 13 46 27" src="https://user-"
Fixed by
Change:
exit(_code?: number | undefined): void { nativeClose(); } <del> async exists(_path: string): Promise<boolean> { return true; } async realpath(path: string): Promise<string> { return path; } </del> };

Discussion:
Steps to repro: (prereq) make sure Python is installed in or (also repros with stable , does not repo in Desktop) open or wait a bit see that Python gets activated even though this repo has nothing python-y in it (just XML files) ! informed me of which gave me a very curious output: What’s interesting about this is that this repo has no , no , no … so this takes me to the original question. Why is this causing activation? After chatting a bit, pointed out: as suspicious.
I think these host methods are not implemented correctly and they might be the root cause:
Yeah, the function isn't really implemented. Tho, I could change the default to to but the bigger challenge is that the interface assumes local file access - it talks about paths, not uris and therefore this will be hard to implement. And by extension I also think this is buggy for the node EH with workspace not hosted on local disk
NVM - I found the magic and will use that for web EH
Change:
overviewRulerWidth: 10, ignoreBracketedPasteMode: config.ignoreBracketedPasteMode, rescaleOverlappingGlyphs: config.rescaleOverlappingGlyphs, <ins> windowOptions: { getWinSizePixels: true, getCellSizePixels: true, getWinSizeChars: true, }, </ins> })); this._updateSmoothScrolling(); this._core = (this.raw as any)._core as IXtermCore;

Discussion:
VS Code Version: Version: 1.87.2 OS Version: macOS 13.6.4 Steps to Reproduce: in the terminal happens in in , see that IWindowOptions is empty What should happen (works in iTerm2 and macOS Terminal): in the terminal should see a report printed to the screen The window size reporting functions are useful when connecting through tunnels that do not support TTY resize event forwarding. While many SSH and Telnet clients do support this, some tunnels do not (for example, a raw socket tunnel to a vt220-supporting application) and some programs may assume that the client supports this escape sequence. The information required to determine the terminal size in character is already available and is currently used to set the TTY's size. This function is fully implemented in , but not vscode. A small proof-of-concept where I use the debugger to enable this option appears to work as expected.