jiebi/CodeConvo huggingface dataset:
Code change:
switchSides = localize('switchSidesNoKb', "Run the command Diff Editor: Switch Side, which is currently not triggerable via keybinding, to toggle between the original and modified editors."); } <ins> const diffEditorActiveAnnouncement = localize('msg5', "The setting, accessibility.verbosity.diffEditorActive, controls if a diff editor announcement is made when it becomes the active editor."); </ins> const keys = ['accessibility.signals.diffLineDeleted', 'accessibility.signals.diffLineInserted', 'accessibility.signals.diffLineModified']; const content = [ localize('msg1', "You are in a diff editor."), localize('msg2', "View the next ({0}) or previous ({1}) diff in diff review mode, which is optimized for screen readers.", next, previous), switchSides, <ins> diffEditorActiveAnnouncement, </ins> localize('msg4', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), ]; const commentCommandInfo = getCommentCommandInfo(keybindingService, contextKeyService, codeEditor);

Related discussion:
text: has said that when switching between editors, it's unclear to him when a diff editor has been entered, though this is clear for sighted users. We should something like to fix this. cc
I think we announce whenever an editor gets focus. Each editor has a title that is announced. So I am not sure what is missing here? I would not like that we just add a new alert. Is the title of the diff editor not descriptive enough? Or is nothing getting announced (which would be a bug)
Good point, the file name is announced and says (Working Tree). is that sufficient to indicate this?
Closing for now, but will reopen based on your feedback
Just discussed with JooYoung and the redundant info is escaped/ignored by screen reader users, so we need to alert with this info
Should we consider a better announcement on focus of the text editor? how does this interact with the existing announcement?
Venkatesh observed that the editor title isn't being read at all, only the accessibility help hint, need to investigate that. EDIT: I explored and this works as expected.
Edit: we use already. This is working as expected. When a new file is opened, the title is read. When a user focuses the document, they hear the hint, if any, along with the "edit text, ...content". If that hint is disabled, they hear "edit text,...content"
which command do you use to switch between editor tabs? Is it ? I believe this issue is about when using that command, indicating if the focused editor is a diff editor via an .
What should I be looking for when verifying this?
Have some editor groups open, including ones with diff editors. Run the command . When a diff editor group is focused, you should hear "diff editor" announced by a screen reader. Disable that setting, and ensure you don't hear that. You should also hear it when navigating the open editors view. !
Using the Open Editors view, I don't see anything read about diff editors when I hit on a diff editor: !
Actually, I do see it when I toggle accessibility mode on
Code change:
}; const spanElement = (this.message.formatContent <del> ? renderFormattedText(this.message.content, renderOptions) : renderText(this.message.content, renderOptions)); </del> <ins> ? renderFormattedText(this.message.content!, renderOptions) : renderText(this.message.content!, renderOptions)); </ins> spanElement.classList.add(this.classForType(this.message.type)); const styles = this.stylesForType(this.message.type);

Related discussion:
text: Type: <bBug</ba file for which a DocumentSymbolProvider will return some items, for example on the filename in the breadcrumb, then type Ctrl/Cmd+F. The list filter widget looks OK, though it hides the first filename in the list ( ought to help with this once merged). the same but one item to the right in the breadcrumb. The filter widget is transparent. ! VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-22T05:16:19.478Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes <!-- generated by issue reporter --
/assign
Easier steps: <kbdCtrl F</kbdon an outline breadcrumb
I still see this. It looks like the background of the find widget gets removed, but the contents still scroll up out of the breadcrumbs widget
Did you test this in dev? Because we still didn't get an Insiders build with the fix.
Code change:
}; const spanElement = (this.message.formatContent <del> ? renderFormattedText(this.message.content, renderOptions) : renderText(this.message.content, renderOptions)); </del> <ins> ? renderFormattedText(this.message.content!, renderOptions) : renderText(this.message.content!, renderOptions)); </ins> spanElement.classList.add(this.classForType(this.message.type)); const styles = this.stylesForType(this.message.type);

Related discussion:
text: Originally posted by in
This also happens if step 5 is omitted and Search mode is used. The problem seems to be that to put the 'No elements found.' warning message under the find-in-list's input widget a ContextView is created immediately below it. But when find is occurring in a breadcrumb list, that list is itself in a ContextView which gets hidden and cleared immediately before the one for the warning message is shown. The warning message appears in the top left of the VS Code window in a very narrow column. See below, where I open , click on the filename in the breadcrumb to get a list of sibling filenames, then type "z" which isn't present in any of the filenames. !
Code change:
{ "name": "code-oss-dev", "version": "1.94.0", <del> "distro": "0e2e9472d115a44f86c2cc3ea26fcea692643ec3", </del> <ins> "distro": "a27dc893952c71fcdc7dc52f9ea3fe51add4fe83", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: Testing Version: 1.90.0-insider Commit: Date: 2024-05-29T05:51:07.154Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 5.15.0-107-generic open a file in an editor run . This opens a file selection dialog initialized to the home folder
Same problem with open folder dialog
VS Code is awesome, but the open file dialog on Linux has been ridiculously buggy for years. More than two years to fix the problem of the dialog opening in the background. The fix, in the latest version, involves using a dialog inside a portal with no type-ahead support that opens in $HOME or recent files. The open/save file dialog is a crucial control in any application. There should be a way to use the native OS dialog. I'm going to downgrade to the previous version (1.89.1) and keep it as long as it takes.
cc
We hadn't patched the portal code to support most of the file dialogs options, it is being addressed via
This is now addressed in the runtime via , fix will be available once we adopt
Reopening since we have reverted the updated due to other regressions , will be revisited in August.
This issue is not resolved for me, here is for comparison how the file dialog opens in an older version of VS Code vs. now: Good behaviour: ! Bad behaviour: !
Filed
I'm on xfce on xubuntu 22.04. Version 1.89.1-1715060508_amd64 does not have the issue. Later versions do have it. The problem is that instead of forcing the "Open File" path, to that of the current file being edited, vscode delegates the path selection to the operating system, which resolves the "Recent Files" path. Since recent files is truly not useful in vscode, I can at least pilot the path to be that of the home folder with $gsettings set startup-mode 'cwd' from the previous value. Clearly this is very inconvenient. Is there any update about it?
The issue is not resolved for me either.
Code change:
{ "name": "code-oss-dev", "version": "1.94.0", <del> "distro": "0e2e9472d115a44f86c2cc3ea26fcea692643ec3", </del> <ins> "distro": "a27dc893952c71fcdc7dc52f9ea3fe51add4fe83", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: The file-open and directory-open dialogs still do not appear even though built on Electron 30.1.2. This is reproducible 100% of the time in openSUSE Tumbleweed and in Leap.
The file-open/directory-open or save dialog not being shown remains unresolved on Linux in release 1.93.1 built with electron 30.4.0.
Code change:
return editor.getContribution<EditorDictation>(EditorDictation.ID); } <del> private readonly widget = this._register(new DictationWidget(this.editor)); </del> <ins> private readonly widget = this._register(new DictationWidget(this.editor, this.keybindingService)); </ins> private readonly editorDictationInProgress = EDITOR_DICTATION_IN_PROGRESS.bindTo(this.contextKeyService); private sessionDisposables = this._register(new MutableDisposable());

Related discussion:
text: Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.
Code change:
const toRender = this._render(visibleStartLineNumber, visibleEndLineNumber, decorationsToRender, this._glyphMarginDecorationLaneCount); const lineHeight = this._lineHeight.toString(); <del> const width = this._glyphMarginWidth.toString(); </del> <ins> const width = (Math.round(this._glyphMarginWidth / this._glyphMarginDecorationLaneCount)).toString(); </ins> const common = '" style="width:' + width + 'px' + ';height:' + lineHeight + 'px;'; const output: string[] = [];

Related discussion:
text: Presumably related to . Adding breakpoints to lines with gutter icons causes the icon to be stretched and cropped: ! I don't know if related, but I'm using :
The problem is that we set each decoration 's width to be the width of the entire gutter (which is sized to fit potentially multiple decorations, so sets which ends up stretching the decoration to fit the entire gutter instead of just its lane.
Fix looks good, thanks! /verified
Code change:
import { Selection } from 'vs/editor/common/core/selection'; import { SingleTextEdit, TextEdit } from 'vs/editor/common/core/textEdit'; import { TextLength } from 'vs/editor/common/core/textLength'; <ins> import { ScrollType } from 'vs/editor/common/editorCommon'; </ins> import { Command, InlineCompletionContext, InlineCompletionTriggerKind, PartialAcceptTriggerKind } from 'vs/editor/common/languages'; import { ILanguageConfigurationService } from 'vs/editor/common/languages/languageConfigurationRegistry'; import { EndOfLinePreference, ITextModel } from 'vs/editor/common/model';

Related discussion:
text: type at the end of line have ghost text accept it word by word when reaching the end of the viewport accepted words aren't revealed https://user-
fyi that I have pushed as a fix for this
Thank you! Sorry for not fixing this, I thought the fix was more complicated.
Accepting single word seems to move the horizontal scroll, but tabbing to accept the whole line does not scroll. Is that expected?
Marking as verified as word by word works.
Code change:
return this._commentThread; } <ins> public get expanded(): boolean | undefined { return this._isExpanded; } </ins> private _commentOptions: languages.CommentOptions | undefined; constructor(

Related discussion:
text: VSCode Version: 1.36.0 OS Version: Windows 10 Repro steps: Live Share extension 1.0.488, start a collaboration session two comment threads on a single line. Comment on a line, 3 for example Comment on a second line, 4 for example Delete line 3 Now there are two comment threads on line 3 (the line that moved up from 4) /Collapse the comments with the marker Collapsing/opening such comments might need a rework. Currently I can collapse each individually, and if all are collapsed (or all open), the box on the gray line opens (or closes) all threads. However, if only some of the threads are collapsed, the gray box toggles between the set of open threads and the threads which were collapsed. It never collapses all threads to return to code, and requires each remaining thread to be collapsed individually. Originally reported in Live Share issue
As I was just about to file the same thing, here is the screencast I created for illustration: !
I agree the current behavior is a bit confusing. Clicking in the gutter is a common way to collapse open comments. However, the workflow fails when multiple comments are on the same line. This forces the user to think and use the alternative workflow (top-right icon). Suggested behavior: if at least one comment is expanded, collapse all comments on the line otherwise, expand all the comments The condition could also be reversed (expand if the line has both expanded and collapsed comments).
Since we just came across the relevant code again in another context: clicks on the gutter icon currently toggle the collapsible states for all threads on that line independently here: already exists as a private property, if there was a public getter for it, behavior like the one suggested by above could probably be implemented very locally in the location I linked to above. let us know if that sounds reasonable and we can make a PR.
yes, this sounds reasonable to me. l would accept a PR!
I opened .
Code change:
getDefaultShell(options: IShellLaunchConfigResolveOptions): Promise<string>; getDefaultShellArgs(options: IShellLaunchConfigResolveOptions): Promise<string | string[]>; getEnvironment(remoteAuthority: string | undefined): Promise<IProcessEnvironment>; <del> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | undefined>; </del> <ins> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | string>; </ins> } export interface IShellLaunchConfigResolveOptions {

Related discussion:
text: Testing With the following settings: I saw the terminal migration notification and then clicked "Migrate", and my settings changed to: Which is defintely not what I expected to happen.
Perhaps if the shell/shellArgs match one of the detected profiles, the name of that profile can be used? So in the sample above,
I'm also kinda confused by this... here's what I had: and it turned it into:
The behavior should be: If there is an exact match (eg. just ), it should assign the existing profile as the default (). If there is not an exact match (eg. ), it should add the profile to the list and set it as the default. As for the name maybe something like would be best.
To verify, see and try other combinations
or could you pls verify this?
with the following: I don't get a notification. Is that expected?
If you've already said don't show again to the notification in that workspace, yes.
ah... I hit the which didn't show the notification until I reloaded the window.
that was another fix that went in to make sure we're not annoying
Migration doesn't seem to be working for me. Here's a gif: ! These are the same settings as here
Ah looks like if I already define then this migration doesn't work. If I delete that setting (and use instead as the default profile, the migration works.
Meaning if you set the to the name of a profile that already exists within your it doesn't work? I think that's by design.
Gotcha. The only thing I'll mention is this, with a defined does not prompt me: but this without it defined does prompt me:
I guess I would expect the migration to still happen (and a new profile be to my existing ) but maybe that's out of scope.
That seems wrong. It should happen as long as you haven't said don't show again. I'll try it.
ah... just opened dev tools:
it's working for me on Windows.
Hmm what does that mean?
Here's a repro on non-Windows without PowerShell:
any errors in dev tools with that repro? can you turn on trace logging? and search for 'migrat'
Beyond this: I don't see anything... which Output should I dig into specifically?
Run set log level -trace -open developer tools.
Code change:
getDefaultShell(options: IShellLaunchConfigResolveOptions): Promise<string>; getDefaultShellArgs(options: IShellLaunchConfigResolveOptions): Promise<string | string[]>; getEnvironment(remoteAuthority: string | undefined): Promise<IProcessEnvironment>; <del> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | undefined>; </del> <ins> createProfileFromShellAndShellArgs(shell?: unknown, shellArgs?: unknown): Promise<ITerminalProfile | string>; </ins> } export interface IShellLaunchConfigResolveOptions {

Related discussion:
text: you should see a migration message. migrated from shell/shellArgs...
I wonder if this could be the issue
Hmmm I don't see
The fix here is probably:
Even better is marking the type as readonly too:
We might be able to catch this in the future with
I don't understand what's going wrong here though - if userValue is undefined, profiles get set to already
I'd think making it readonly would be even worse since then we can't add properties to it - such as the newly created profile
Which works fine, the failure case was when had profiles set. The there just corrects the type we're receiving from the config service
ok, should this be a candidate or moved to June?
I think it meets the candidate bar, we really want migration to be solid
Code change:
this._matchesCount.className = 'matchesCount'; } this._matchesCount.innerText = ''; <del> const label = count === undefined || count.resultCount === 0 ? `No Results` : `${count.resultIndex + 1} of ${count.resultCount}`; </del> <ins> let label; if (count?.resultCount === -1) { label = ''; } else { label = count === undefined || count.resultCount === 0 ? NLS_NO_RESULTS : strings.format(NLS_MATCHES_LOCATION, count.resultIndex + 1, count?.resultCount); } </ins> this._matchesCount.appendChild(document.createTextNode(label)); this._matchesCount.classList.toggle('no-results', !count || count.resultCount === 0); this._findInput?.domNode.insertAdjacentElement('afterend', this._matchesCount);

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -
Code change:
getSelection(): (MarkerTableItem | null)[] { const selection = this.table.getSelection(); <del> return selection.length > 0 ? [this.table.row(selection[0])] : []; </del> <ins> return selection.length > 0 ? [...selection.map(i => this.table.row(i))] : []; </ins> } getVisibleItemCount(): number {

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
"@typescript-eslint/eslint-plugin": "^5.57.0", "@typescript-eslint/experimental-utils": "^5.57.0", "@typescript-eslint/parser": "^5.57.0", <del> "@vscode/gulp-electron": "^1.35.0", </del> <ins> "@vscode/gulp-electron": "^1.36.0", </ins> "@vscode/l10n-dev": "0.0.21", "@vscode/telemetry-extractor": "^1.9.9", "@vscode/test-web": "^0.0.41",

Related discussion:
text: Today when running out of sources and/or building, we get some components from online resources such as GitHub or our Marketplace. We should add SHA256 checksum verification to these: [x] [x] built-in extensions [x] electron
Adding the foundation for this for and extensions in
Code change:
getFocus(): (MarkerTableItem | null)[] { const focus = this.table.getFocus(); <del> return focus.length > 0 ? [this.table.row(focus[0])] : []; </del> <ins> return focus.length > 0 ? [...focus.map(f => this.table.row(f))] : []; </ins> } getHTMLElement(): HTMLElement {

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
async resetLocal(): Promise<void> { this.checkEnablement(); this.storageService.remove(LAST_SYNC_TIME_KEY, StorageScope.APPLICATION); <del> if (this.activeProfileSynchronizers) { for (const [synchronizer] of this.activeProfileSynchronizers.values()) { try { await synchronizer.resetLocal(); } catch (e) { this.logService.error(e); } </del> <ins> for (const [synchronizer] of this.activeProfileSynchronizers.values()) { try { await synchronizer.resetLocal(); } catch (e) { this.logService.error(e); </ins> } <del> this.clearActiveProfileSynchronizers(); </del> } <ins> this.clearActiveProfileSynchronizers(); </ins> this._onDidResetLocal.fire(); this.logService.info('Did reset the local sync state.'); }

Related discussion:
text: Error while turning off settings sync ! Might happen when turning off settings sync while a sync is happening
Can't repro this anymore.
Code change:
"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Related discussion:
text: Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.
Code change:
"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Related discussion:
text: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?