Question:
Testing No matter whether I use or set it to some other keybinding, I cannot seem to invoke this command with a keyboard shortcut--only from the command palette.
I cannot repro on mac, windows, or linux, could you pls run and provide me with the logs? The terminal has to be focused btw for it to work
Yeah the terminal was focused in my testing. Weirdly enough, seems to work now--definitely wasn't working before though.
I've run into this as well. Here's the output when turned on Toggle Keyboard Shortcuts Troubleshooting: 2023-01-24 19:45:48.902 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:48.925 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:48.925 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:48.925 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:48.925 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.404 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.404 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.404 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.405 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.405 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.435 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.435 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.435 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.435 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.435 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.482 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.482 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.482 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.483 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.483 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.513 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.514 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.514 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.514 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.514 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.544 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.545 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.545 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.545 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.545 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.577 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.577 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.577 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.577 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.578 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.608 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.608 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.608 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.608 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.609 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.641 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.642 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.642 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.643 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.643 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.673 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.673 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.674 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.674 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.675 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.703 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.703 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.703 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.703 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.704 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.735 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.736 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.736 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.736 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.736 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.767 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.767 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.767 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.768 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.768 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.798 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.798 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.798 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.799 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.799 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.844 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.844 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.845 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.845 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.845 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.877 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.877 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.878 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.878 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.879 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.907 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.908 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:49.909 [info] [KeybindingService]: / Received keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 16, key: Shift 2023-01-24 19:45:49.909 [info] [KeybindingService]: | Converted keydown event - modifiers: [shift], code: ShiftLeft, keyCode: 4 ('Shift') 2023-01-24 19:45:49.910 [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. 2023-01-24 19:45:49.916 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:49.917 [info] [KeybindingService]: | Resolving shift+F1 2023-01-24 19:45:49.917 [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalProcessSupported, source: built-in. 2023-01-24 19:45:50.063 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:50.063 [info] [KeybindingService]: | Resolving shift+F1 2023-01-24 19:45:50.063 [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalProcessSupported, source: built-in. 2023-01-24 19:45:50.483 [info] [KeybindingService]: / Soft dispatching keyboard event 2023-01-24 19:45:50.483 [info] [KeybindingService]:  Keyboard event cannot be dispatched 2023-01-24 19:45:50.484 [info] [KeybindingService]: + Ignoring single modifier shift due to it being pressed together with other keys.
This was on my Surface with Windows 11. I wonder if it has to do with needing to press the Windows function key to get my F1 key? I need to do Shift + Function + F1 as without the Function key, F1 is the screen dimmer. Alt+Function+F1 works for showing the regular accessibility help. I wonder what that code is doing to work?
This is expected as to use , the function key needs to be activated. in the terminal does funny things on Windows/Linux, which is why we went with instead here
On Windows, when I set the keybinding to , it's not a valid chord and the result from the keybinding service is . That's true even when I set the weight for our action to be greater than workbench contrib. It doesn't work even when I set . Thus, we need to stick with here and the function key has to be used before pressing . !
shift+f1 isn't working for me

TerminalCommandId.SelectNextPageSuggestion, TerminalCommandId.AcceptSelectedSuggestion, TerminalCommandId.HideSuggestWidget, <ins> TerminalCommandId.ShowTerminalAccessibilityHelp, </ins> 'editor.action.toggleTabFocusMode', 'notifications.hideList', 'notifications.hideToasts',


Question:
Testing Here is the description of this setting Controls whether the suggest widget becomes active when triggered via quick suggest or trigger characters. Note that the widget is always active when explicitly invoked, e.g via Ctrl+Space. It was not clear to me what active means. After trying around I figured out that its about the default selection of the first suggestion in the widget. Setting itself calls rather than . Hence I would recommend to explain in the description that this setting is about controlling the selection of the suggestion. Like Controls the selection of the options in the suggest widget when triggered via quick suggest or trigger characters. Note that the first suggestion is always selected when explicitly invoked, e.g via Ctrl+Space.
It's not always the first suggestion - there is yet another setting to define what element is default-"selected". The problem is that technically this isn't selection (because selecting inserts the item) and also not focus (because focus remains in the editor). I used selection mode because that's how VS calls it but I understand the issue and I open for a better setting name and better description. Maybe we should just talk about focus?
I think keeping selection isn't bad but maybe the working should say "Controls whether a suggestion is selected when triggered via quick suggest or trigger characters..."

type: 'string', enum: ['always', 'never', 'whenTriggerCharacter', 'whenQuickSuggestion'], enumDescriptions: [ <del> nls.localize('suggest.insertMode.always', "Always activate the suggest widget when triggering IntelliSense automatically."), nls.localize('suggest.insertMode.never', "Never activate the suggest widget when triggering IntelliSense automatically."), nls.localize('suggest.insertMode.whenTriggerCharacter', "Activate the suggest widget only when triggering IntelliSense from a trigger character."), nls.localize('suggest.insertMode.whenQuickSuggestion', "Activate the suggest widget only when triggering IntelliSense as you type."), </del> <ins> nls.localize('suggest.insertMode.always', "Always select a suggestion when automatically triggering IntelliSense."), nls.localize('suggest.insertMode.never', "Never select a suggestion when automatically triggering IntelliSense."), nls.localize('suggest.insertMode.whenTriggerCharacter', "Select a suggestion only when triggering IntelliSense from a trigger character."), nls.localize('suggest.insertMode.whenQuickSuggestion', "Select a suggestion only when triggering IntelliSense as you type."), </ins> ], default: defaults.selectionMode, <del> markdownDescription: nls.localize('suggest.selectionMode', "Controls whether the suggest widget becomes active when triggered via quick suggest or trigger characters. Note that the widget is always active when explicitly invoked, e.g via `Ctrl+Space`.") </del> <ins> markdownDescription: nls.localize('suggest.selectionMode', "Controls whether a suggestion is selected when the widget shows. Note that this only applies to automatically triggered suggestions (`#editor.quickSuggestions#` and `#editor.suggestOnTriggerCharacters#`) and that a suggestion is always selected when explicitly invoked, e.g via `Ctrl+Space`.") </ins> }, 'editor.suggest.snippetsPreventQuickSuggestions': { type: 'boolean',


Question:
I took one of the suggested results from intellisense and it inserted a literal star symbol into my code ]()
I also have been seeing this since yesterday, using JS specifically The star has always been present in the intellisense list, but never included in the text filled in.
Also reproduced this behaviour while verifying another issue !
This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the for VS Code. See also our . If you don't know which extension is causing the problem, you can run from the command palette (F1) to help identify the problem extension. Happy Coding!
Caused by IntelliCode:
This issue only occurs in Insiders, and does not occur in Stable. Downgrading to an older version of the extension also does not fix the issue. Therefore, I'm wondering whether the completions API implementation changed. the IntelliCode extension (VisualStudioExptTeam.vscodeintellicode). a new JS file. and wait for the IntelliCode completions to show up. If they don't show up, backspace and try again. The IntelliCode completions will have a star in front of them. one of the IntelliCode completions. :bug: In Insiders, the star character is to the editor.
I've disabled Microsoft Intellicode (AI-assisted development, ID: VisualStudioExptTeam.vscodeintellicode) until they fix it back. All good for know.
This is somehow happening in the TypeScript extension. In the UI, when inserting the completion, we have an insert text with a leading . So, the UI is doing what it is told to do. <img width="1403" alt="Screenshot 2023-01-27 at 09 30 21" src="https://user-"Seemingly, in the TS extension the right data is received but somehow a wrong API completion is generated <img width="628" alt="Screenshot 2023-01-27 at 09 34 39" src="https://user-"
Mostly likely regressed via
Confirmed. This is the faulty statement The OR-statement binds stronger than the ternary operator and therefore the label always replaces the insertText

this.filterText = this.getFilterText(completionContext.line, tsEntry.insertText); if (completionContext.isMemberCompletion && completionContext.dotAccessorContext && !(this.insertText instanceof vscode.SnippetString)) { <del> this.filterText = completionContext.dotAccessorContext.text + (this.insertText || typeof this.label === 'string' ? this.label : this.label.label); </del> <ins> this.filterText = completionContext.dotAccessorContext.text + (this.insertText || this.textLabel); </ins> if (!this.range) { const replacementRange = this.getFuzzyWordRange(); if (replacementRange) {


Question: <!-- 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: 1.75.0-insider OS Version: Windows 11 (21H2, .1455) Steps to Reproduce: editor with CSS/SCSS syntax CSS block e.g. to use Emmet CSS completion with abbreviation of more than 1 character that no Emmet completions are provided Emmet completions seem to only be provided for single-character abbreviations: ! For multi-character abbreviations, I am not getting any results from Emmet at all: ! A of the issue suggests that it was introduced in commit as part of More testing shows some weird behaviour when providing completions, with them showing sometimes but not always when expected: Type - text is - Emmet suggests Type - text is - no suggestions Type - text is - no suggestions Type - text is - Emmet suggests Backspace - text is - Emmet suggests Backspace - text is - Emmet suggests

}); } <del> return new vscode.CompletionList(newItems); </del> <ins> return new vscode.CompletionList(newItems, true); </ins> }); } }


Question: off the hot exit and auto save settings an interactive window, run a cell vscode :bug: confirmation pop-up to save the IW

import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { ICellDto2, INotebookEditorModel, INotebookLoadOptions, IResolvedNotebookEditorModel, NotebookCellsChangeType, NotebookData } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <ins> import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> import { IFileWorkingCopyManager } from 'vs/workbench/services/workingCopy/common/fileWorkingCopyManager'; import { IStoredFileWorkingCopy, IStoredFileWorkingCopyModel, IStoredFileWorkingCopyModelContentChangedEvent, IStoredFileWorkingCopyModelFactory, IStoredFileWorkingCopySaveEvent, StoredFileWorkingCopyState } from 'vs/workbench/services/workingCopy/common/storedFileWorkingCopy'; import { IUntitledFileWorkingCopy, IUntitledFileWorkingCopyModel, IUntitledFileWorkingCopyModelContentChangedEvent, IUntitledFileWorkingCopyModelFactory } from 'vs/workbench/services/workingCopy/common/untitledFileWorkingCopy';


Question: off the hot exit and auto save settings an interactive window, run a cell vscode :bug: confirmation pop-up to save the IW

private readonly _hasAssociatedFilePath: boolean, readonly viewType: string, private readonly _workingCopyManager: IFileWorkingCopyManager<NotebookFileWorkingCopyModel, NotebookFileWorkingCopyModel>, <del> @IFileService private readonly _fileService: IFileService </del> <ins> @IFileService private readonly _fileService: IFileService, @ILifecycleService lifecycleService: ILifecycleService </ins> ) { super(); <ins> if (this.viewType === 'interactive') { lifecycleService.onBeforeShutdown(async e => e.veto(this.onBeforeShutdown(), 'veto.InteractiveWindow')); } } private async onBeforeShutdown() { if (this._workingCopy?.isDirty()) { await this._workingCopy.save(); } return false; </ins> } override dispose(): void {


Question:
In virtual workspaces, the file dialog has a button. There's no such dialog in remote windows--the file dialog always shows the remote filesystem. This is an issue for continuing from a GitHub codespace to a local desktop clone when the user is in VS Code desktop. Suggestion: when in a virtual or remote window on desktop, always have the 'Show Local' option in the file dialog.
Oh interesting--there is a Show Local in the Open Folder flow, but not when the git extension invokes the file dialog: <img width="671" alt="image" src="https://user-"
I see this was an intentional decision for extension access to the simple file dialog in a remote window in for However that makes it hard to go from a remote window to a local one from extension land. Is this something that we can expose to extensions via a new proposed api option for the file dialog?
Duplicate of , which is an API request to expose "show local".
Reopening this to track adoption of in the Continue On flow.
Steps: Open a codespace in VS Code desktop From the remote indicator, choose Continue in Local Clone Ensure that the repo gets cloned successfully to your local machine

if (uri !== undefined) { // Launch desktop client if currently in web <ins> let target = `${env.uriScheme}://vscode.git/clone?url=${encodeURIComponent(uri)}`; </ins> if (env.uiKind === UIKind.Web) { <del> let target = `${env.uriScheme}://vscode.git/clone?url=${encodeURIComponent(uri)}`; </del> if (ref !== undefined) { target += `&ref=${encodeURIComponent(ref)}`; } return Uri.parse(target); } <del> // If already in desktop client, directly clone </del> <ins> // If already in desktop client but in a remote window, we need to force a new window // so that the git extension can access the local filesystem for cloning if (env.remoteName !== undefined) { target += `&windowId=_blank`; return Uri.parse(target); } // Otherwise, directly clone </ins> void this.clone(uri, undefined, { ref: ref }); } }


Question:
Type: <bBug</btypescript server keeps crashing after the latest update VSCODE ! I can reproduce this with all the extensions disabled. LOG: ! VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-03T05:23:17.202Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ ng-template15.1.0 atlascode3.0.1 vscode-markdownlint0.49.0 vscode-eslint2.2.6 githistory0.6.19 gitlens13.2.0 prettier-vscode9.10.4 vscode-yaml1.11.0 sonarlint-vscode3.14.0 code-spell-checker2.16.0 vscode-stylelint1.2.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please try collecting the TS Server log from the crashed instance: VS Code and reproduce the problem the section of the output panel the very top, find the first line that prints to path to the semantic error log file. It should look something like: That file contains the typescript logs. Look through that log file for the first error or stack trace you see. If you can share the log, I can also take a look to see if anything stands out
, for some reason the log file location is shown as [Object object] (as pointed out by the pink arrow), I checked in the folder pointed out by the red arrow and the folder is empty. ! I have checked this for multiple folder I could see in the log prompt but all of them are empty.
a Microsoft member created same/duplicate issue , in case this could help with the debugging
Confirming that I also see when using verbose setting and all the log files are empty for me, which is also noted and shown on microsoft/vscode.
For me the directory under the object object is also empty, is that the case with you?
Yes, same.
should be fixed in the next insider release: microsoft/vscode
the object object issue is resolved, however, the file pointed by the log still does not exist. can you give it a try if you can see the logs?
i did some commenting in the file and found that commenting out setting stops the repeated crash. Note: I am not sure why I have /enabled this setting in the first place.
Oh wow, exactly the same for me. I also do not remember ever setting , but it was in my and removing it fixes the crash for me too!
Also confirming that with latest update is fixed but log directories are still empty. I've closed my bug as a duplicate of this one since it's pretty clear these are the same issue now. Are you able to repro using is Also do you know if this would ever have been set on user's behalf, which could impact the severity here if lots of people would have this in their settings?
Thanks and I can confirm that enabling cause the server to crash on windows. Oddly I don't see it on Mac. The server is likely crashing before logging can start too, which is why the log files don't exist I'm not sure how this setting got enabled for you. It's only meant for detailed performance investigations and should never be turned on automatically
Yay, thank you and

if (configuration.enableTsServerTracing) { if (tsServerTraceDirectory) { <del> this._logger.info(`<${kind}> Trace directory: ${tsServerTraceDirectory}`); </del> <ins> this._logger.info(`<${kind}> Trace directory: ${tsServerTraceDirectory.fsPath}`); </ins> } else { this._logger.error(`<${kind}> Could not create trace directory`); }


Question:
Type: <bBug</btypescript server keeps crashing after the latest update VSCODE ! I can reproduce this with all the extensions disabled. LOG: ! VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-03T05:23:17.202Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ ng-template15.1.0 atlascode3.0.1 vscode-markdownlint0.49.0 vscode-eslint2.2.6 githistory0.6.19 gitlens13.2.0 prettier-vscode9.10.4 vscode-yaml1.11.0 sonarlint-vscode3.14.0 code-spell-checker2.16.0 vscode-stylelint1.2.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please try collecting the TS Server log from the crashed instance: VS Code and reproduce the problem the section of the output panel the very top, find the first line that prints to path to the semantic error log file. It should look something like: That file contains the typescript logs. Look through that log file for the first error or stack trace you see. If you can share the log, I can also take a look to see if anything stands out
, for some reason the log file location is shown as [Object object] (as pointed out by the pink arrow), I checked in the folder pointed out by the red arrow and the folder is empty. ! I have checked this for multiple folder I could see in the log prompt but all of them are empty.
a Microsoft member created same/duplicate issue , in case this could help with the debugging
Confirming that I also see when using verbose setting and all the log files are empty for me, which is also noted and shown on microsoft/vscode.
For me the directory under the object object is also empty, is that the case with you?
Yes, same.
should be fixed in the next insider release: microsoft/vscode
the object object issue is resolved, however, the file pointed by the log still does not exist. can you give it a try if you can see the logs?
i did some commenting in the file and found that commenting out setting stops the repeated crash. Note: I am not sure why I have /enabled this setting in the first place.
Oh wow, exactly the same for me. I also do not remember ever setting , but it was in my and removing it fixes the crash for me too!
Also confirming that with latest update is fixed but log directories are still empty. I've closed my bug as a duplicate of this one since it's pretty clear these are the same issue now. Are you able to repro using is Also do you know if this would ever have been set on user's behalf, which could impact the severity here if lots of people would have this in their settings?
Thanks and I can confirm that enabling cause the server to crash on windows. Oddly I don't see it on Mac. The server is likely crashing before logging can start too, which is why the log files don't exist I'm not sure how this setting got enabled for you. It's only meant for detailed performance investigations and should never be turned on automatically
Yay, thank you and

if (configuration.enableTsServerTracing && !isWeb()) { tsServerTraceDirectory = this._logDirectoryProvider.getNewLogDirectory(); if (tsServerTraceDirectory) { <del> args.push('--traceDirectory', tsServerTraceDirectory.path); </del> <ins> args.push('--traceDirectory', tsServerTraceDirectory.fsPath); </ins> } }


Question:
Bug The the following entry in its : This seems to cause the python extension to be activated whenever a json file is opened, even though the extension does not provide any json language support This was possibly caused by the move to automatic activation events
I think my initial implementation of implicit activation was perhaps too naive. There seem to be a few issues: It's possible to have a language configuration extension that doesn't contribute any code, and we would now attempt to activate such an extension (this is a noop if there is no main/browser entrypoint in , but results in unnecessary activation if all that's required is a language configuration) the bigger issue is that an extension which contributes extensions, filenames, filenamePatterns, firstLine, or mimeTypes for a language will now get activated anytime the language appears I think it's maybe reasonable to preserve the existing implicit activation behavior if an alias is defined for all of the others, we shouldn't infer , or we should perhaps keep track of the filenames/filenamePatterns etc and activate the extension with the language contribution matching the specified pattern? I know of at least two extensions which are impacted by the current behavior MakeCode Python
:+1: This makes good sense to me. We will infer only for the one which is the "main" language definition, and the best evidence of that is the alias property. I wouldn't do anything beyond that (i.e. tracking filenames, patterns, etc.)
Would the presence of the property be better evidence of a contribution being the main language definition?
injection based syntax highlighting can still have a configuration file

const languageContributions = findNodeAtLocation(tree, ['contributes', 'languages']); languageContributions?.children?.forEach(child => { const id = findNodeAtLocation(child, ['id']); <del> if (id && id.type === 'string') { </del> <ins> const configuration = findNodeAtLocation(child, ['configuration']); if (id && id.type === 'string' && configuration && configuration.type === 'string') { </ins> activationEvents.add(`onLanguage:${id.value}`); } });


Question:
Bug The the following entry in its : This seems to cause the python extension to be activated whenever a json file is opened, even though the extension does not provide any json language support This was possibly caused by the move to automatic activation events
I think my initial implementation of implicit activation was perhaps too naive. There seem to be a few issues: It's possible to have a language configuration extension that doesn't contribute any code, and we would now attempt to activate such an extension (this is a noop if there is no main/browser entrypoint in , but results in unnecessary activation if all that's required is a language configuration) the bigger issue is that an extension which contributes extensions, filenames, filenamePatterns, firstLine, or mimeTypes for a language will now get activated anytime the language appears I think it's maybe reasonable to preserve the existing implicit activation behavior if an alias is defined for all of the others, we shouldn't infer , or we should perhaps keep track of the filenames/filenamePatterns etc and activate the extension with the language contribution matching the specified pattern? I know of at least two extensions which are impacted by the current behavior MakeCode Python
:+1: This makes good sense to me. We will infer only for the one which is the "main" language definition, and the best evidence of that is the alias property. I wouldn't do anything beyond that (i.e. tracking filenames, patterns, etc.)
Would the presence of the property be better evidence of a contribution being the main language definition?
injection based syntax highlighting can still have a configuration file

}, activationEventsGenerator: (languageContributions, result) => { for (const languageContribution of languageContributions) { <del> if (languageContribution.id) { </del> <ins> if (languageContribution.id && languageContribution.configuration) { </ins> result.push(`onLanguage:${languageContribution.id}`); } }


const parent = this._options.parentSession; if (parent) { toDispose.add(parent.onDidEndAdapter(() => { <del> // copy the parent repl and get a new detached repl for this child if (!this.hasSeparateRepl()) { </del> <ins> // copy the parent repl and get a new detached repl for this child, and // remove its parent, if it's still running if (!this.hasSeparateRepl() && this.raw?.isInShutdown === false) { </ins> this.repl = this.repl.clone(); replListener.value = this.repl.onDidChangeElements(() => this._onDidChangeREPLElements.fire()); <ins> this.parentSession = undefined; </ins> } <del> this.parentSession = undefined; </del> })); } }


this.debugAdapter.onRequest(request => this.dispatchRequest(request)); } <ins> get isInShutdown() { return this.inShutdown; } </ins> get onDidExitAdapter(): Event<AdapterEndEvent> { return this._onDidExitAdapter.event; }


Question: This is a legit error about a bad URI that came from a debug adapter but I guess we shouldn't send telemetry

if (typeof raw.sourceReference === 'number' && raw.sourceReference > 0) { return URI.from({ scheme: DEBUG_SCHEME, <del> path, </del> <ins> path: path?.replace(/^/+/g, '/'), // #174054 </ins> query: `session=${sessionId}&ref=${raw.sourceReference}` }); }


Question:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

const newWithProfile = nls.localize('newWithProfile', 'The Create New Terminal (With Profile) ({0}) command allows for easy terminal creation using a specific profile.'); const newWithProfileNoKb = nls.localize('newWithProfileNoKb', 'The Create New Terminal (With Profile) command allows for easy terminal creation using a specific profile and is currently not triggerable by a keybinding.'); const accessibilitySettings = nls.localize('accessibilitySettings', 'Access accessibility settings such as `terminal.integrated.tabFocusMode` via the Preferences: Open Accessibility Settings command.'); <ins> const commandPrompt = nls.localize('commandPromptMigration', "Consider using powershell instead of command prompt for an improved experience"); </ins> class AccessibilityHelpWidget extends Widget implements ITerminalWidget { readonly id = 'help'; private _container: HTMLElement | undefined;


Question:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

private readonly _markdownRenderer: MarkdownRenderer; constructor( <del> instance: ITerminalInstance, </del> <ins> private readonly _instance: ITerminalInstance, </ins> @IKeybindingService private readonly _keybindingService: IKeybindingService, @IInstantiationService instantiationService: IInstantiationService, @IOpenerService private readonly _openerService: IOpenerService ) { super(); <del> this._hasShellIntegration = instance.xterm?.shellIntegration.status === ShellIntegrationStatus.VSCode; </del> <ins> this._hasShellIntegration = _instance.xterm?.shellIntegration.status === ShellIntegrationStatus.VSCode; </ins> this._domNode = createFastDomNode(document.createElement('div')); this._contentDomNode = createFastDomNode(document.createElement('div')); this._contentDomNode.setClassName('terminal-accessibility-help');


Question:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

this._register(dom.addStandardDisposableListener(this._contentDomNode.domNode, 'keydown', (e) => { if (e.keyCode === KeyCode.Escape) { this.hide(); <del> instance.focus(); </del> <ins> _instance.focus(); </ins> } })); <del> this._register(instance.onDidFocus(() => this.hide())); </del> <ins> this._register(_instance.onDidFocus(() => this.hide())); </ins> this._markdownRenderer = this._register(instantiationService.createInstance(MarkdownRenderer, {})); }


Question:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

private _buildContent(): void { const content = []; content.push(this._descriptionForCommand(TerminalCommandId.FocusAccessibleBuffer, focusAccessibleBufferNls, focusAccessibleBufferNoKb)); <ins> if (this._instance.shellType === WindowsShellType.CommandPrompt) { content.push(commandPrompt); } </ins> if (this._hasShellIntegration) { content.push(shellIntegration); content.push('- ' + this._descriptionForCommand(TerminalCommandId.RunRecentCommand, runRecentCommand, runRecentCommandNoKb) + 'n- ' + this._descriptionForCommand(TerminalCommandId.GoToRecentDirectory, goToRecent, goToRecentNoKb));


Question:
In our menu, we should mention setting
I actually think we should more broadly mention how to find accessibility settings here -

const dismiss = nls.localize('dismiss', "You can dismiss this dialog by pressing Escape or focusing elsewhere."); const openDetectedLink = nls.localize('openDetectedLink', 'The Open Detected Link ({0}) command enables screen readers to easily open links found in the terminal.'); const openDetectedLinkNoKb = nls.localize('openDetectedLinkNoKb', 'The Open Detected Link command enables screen readers to easily open links found in the terminal and is currently not triggerable by a keybinding.'); <ins> const newWithProfile = nls.localize('newWithProfile', 'The Create New Terminal (With Profile) ({0}) command allows for easy terminal creation using a specific profile.'); const newWithProfileNoKb = nls.localize('newWithProfileNoKb', 'The Create New Terminal (With Profile) command command allows for easy terminal creation using a specific profile and is currently not triggerable by a keybinding.'); const accessibilitySettings = nls.localize('accessibilitySettings', 'Access accessibility settings such as `terminal.integrated.tabFocusMode` via the Preferences: Open Accessibility Settings command.'); </ins> class AccessibilityHelpWidget extends Widget implements ITerminalWidget { readonly id = 'help';


Question:
In our menu, we should mention setting
I actually think we should more broadly mention how to find accessibility settings here -

content.push('- ' + this._descriptionForCommand(TerminalCommandId.RunRecentCommand, runRecentCommand, runRecentCommandNoKb) + 'n- ' + this._descriptionForCommand(TerminalCommandId.GoToRecentDirectory, goToRecent, goToRecentNoKb)); } content.push(this._descriptionForCommand(TerminalCommandId.OpenDetectedLink, openDetectedLink, openDetectedLinkNoKb)); <ins> content.push(this._descriptionForCommand(TerminalCommandId.NewWithProfile, newWithProfile, newWithProfileNoKb)); content.push(accessibilitySettings); </ins> content.push(readMoreLink, dismiss); const element = renderElementAsMarkdown(this._markdownRenderer, this._openerService, content.join('nn'), this._register(new DisposableStore())); const anchorElements = element.querySelectorAll('a');


Question: It should be outside of the output region <img width="962" alt="image" src="https://user-"

.traceback.wordWrap span { white-space: pre-wrap; } <del> .output > .scrollable { </del> <ins> .output .scrollable { </ins> overflow-y: scroll; max-height: var(--notebook-cell-output-max-height); border: var(--vscode-editorWidget-border);


Question: It should be outside of the output region <img width="962" alt="image" src="https://user-"

} function scrollableArrayOfString(id: string, buffer: string[], container: HTMLElement, trustHtml: boolean) { <del> container.classList.add('scrollable'); </del> <ins> const scrollableDiv = document.createElement('div'); scrollableDiv.classList.add('scrollable'); </ins> if (buffer.length > 5000) { container.appendChild(generateViewMoreElement(id, false)); } <del> const div = document.createElement('div'); container.appendChild(div); div.appendChild(handleANSIOutput(buffer.slice(0, 5000).join('n'), trustHtml)); </del> <ins> container.appendChild(scrollableDiv); scrollableDiv.appendChild(handleANSIOutput(buffer.slice(0, 5000).join('n'), trustHtml)); </ins> } export function insertOutput(id: string, outputs: string[], linesLimit: number, scrollable: boolean, container: HTMLElement, trustHtml: boolean) {


Question: Testing have search view open drag the explorer icon onto it the explorer (and npm script) views show the explorer icon stays in the activity bar, the view is empty https://user-

storageId: 'workbench.explorer.views.state', icon: explorerViewIcon, alwaysUseContainerInfo: true, <ins> hideIfEmpty: true, </ins> order: 0, openCommandActionDescriptor: { id: VIEWLET_ID,


Question:
Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell. I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue. The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?
Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.

} }; <del> function scrollWillGoToParent(event: WheelEvent) { </del> <ins> let scrollTimeout: any /* NodeJS.Timeout */ | undefined; let scrolledElement: Element | undefined; function flagRecentlyScrolled(node: Element) { scrolledElement = node; node.setAttribute('recentlyScrolled', 'true'); clearTimeout(scrollTimeout); scrollTimeout = setTimeout(() => { scrolledElement?.removeAttribute('recentlyScrolled'); }, 300); } function eventTargetShouldHandleScroll(event: WheelEvent) { </ins> for (let node = event.target as Node | null; node; node = node.parentNode) { if (!(node instanceof Element) || node.id === 'container' || node.classList.contains('cell_container') || node.classList.contains('markup') || node.classList.contains('output_container')) { return false; } <ins> if (node.hasAttribute('recentlyScrolled') && scrolledElement === node) { flagRecentlyScrolled(node); return true; } </ins> // scroll up if (event.deltaY < 0 && node.scrollTop > 0) { // there is still some content to scroll <ins> flagRecentlyScrolled(node); </ins> return true; }


Question:
Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell. I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue. The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?
Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.

continue; } <ins> flagRecentlyScrolled(node); </ins> return true; } }


Question:
Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell. I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue. The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?
Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.

} const handleWheel = (event: WheelEvent & { wheelDeltaX?: number; wheelDeltaY?: number; wheelDelta?: number }) => { <del> if (event.defaultPrevented || scrollWillGoToParent(event)) { </del> <ins> if (event.defaultPrevented || eventTargetShouldHandleScroll(event)) { </ins> return; } postNotebookMessage<webviewMessages.IWheelMessage>('did-scroll-wheel', {


Question:
Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell. I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue. The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?
Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.

} if (node.hasAttribute('recentlyScrolled')) { <del> if (lastTimeScrolled && Date.now() - lastTimeScrolled > 300) { </del> <ins> if (lastTimeScrolled && Date.now() - lastTimeScrolled > 400) { </ins> // it has been a while since we actually scrolled <del> // if scroll velocity increases, it's likely a new scroll event if (!!previousDelta && deltaY < 0 && deltaY < previousDelta - 2) { </del> <ins> // if scroll velocity increases significantly, it's likely a new scroll event if (!!previousDelta && deltaY < 0 && deltaY < previousDelta - 8) { </ins> clearTimeout(scrollTimeout); scrolledElement?.removeAttribute('recentlyScrolled'); return false; <del> } else if (!!previousDelta && deltaY > 0 && deltaY > previousDelta + 2) { </del> <ins> } else if (!!previousDelta && deltaY > 0 && deltaY > previousDelta + 8) { </ins> clearTimeout(scrollTimeout); scrolledElement?.removeAttribute('recentlyScrolled'); return false;


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

private _tabFocusTerminal: boolean = false; private _tabFocusEditor: boolean = false; <del> private readonly _onDidChangeTabFocus = new Emitter<boolean>(); public readonly onDidChangeTabFocus: Event<boolean> = this._onDidChangeTabFocus.event; </del> <ins> private readonly _onDidChangeTabFocus = new Emitter<void>(); public readonly onDidChangeTabFocus: Event<void> = this._onDidChangeTabFocus.event; </ins> public getTabFocusMode(context: TabFocusContext): boolean { return context === TabFocusContext.Terminal ? this._tabFocusTerminal : this._tabFocusEditor; } public setTabFocusMode(tabFocusMode: boolean, context: TabFocusContext): void { <del> if ((context === TabFocusContext.Terminal && this._tabFocusTerminal === tabFocusMode) || (context === TabFocusContext.Editor && this._tabFocusEditor === tabFocusMode)) { return; } </del> if (context === TabFocusContext.Terminal) { this._tabFocusTerminal = tabFocusMode; } else { this._tabFocusEditor = tabFocusMode; } <del> this._onDidChangeTabFocus.fire(this._tabFocusTerminal); </del> <ins> this._onDidChangeTabFocus.fire(); </ins> } }


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

private readonly languageElement = this._register(new MutableDisposable<IStatusbarEntryAccessor>()); private readonly metadataElement = this._register(new MutableDisposable<IStatusbarEntryAccessor>()); private readonly currentProblemStatus: ShowCurrentMarkerInStatusbarContribution = this._register(this.instantiationService.createInstance(ShowCurrentMarkerInStatusbarContribution)); <ins> private _previousViewContext: 'terminal' | 'editor' | undefined; </ins> private readonly state = new State(); private readonly activeEditorListeners = this._register(new DisposableStore()); private readonly delayedRender = this._register(new MutableDisposable());


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

this._register(this.textFileService.untitled.onDidChangeEncoding(model => this.onResourceEncodingChange(model.resource))); this._register(this.textFileService.files.onDidChangeEncoding(model => this.onResourceEncodingChange((model.resource)))); this._register(Event.runAndSubscribe(TabFocus.onDidChangeTabFocus, () => this.onTabFocusModeChange())); <ins> const viewKey = new Set<string>(); viewKey.add('focusedView'); this._register(this.contextKeyService.onDidChangeContext((c) => { if (c.affectsSome(viewKey)) { const terminalFocus = this.contextKeyService.getContextKeyValue('focusedView') === 'terminal'; const context = terminalFocus ? 'terminal' : 'editor'; if (this._previousViewContext === context) { return; } this._previousViewContext = context; this.onTabFocusModeChange(); } })); </ins> } private registerCommands(): void {


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

import { Schemas } from 'vs/base/common/network'; import { TabFocus, TabFocusContext } from 'vs/editor/browser/config/tabFocus'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <del> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </del> import { ILabelService } from 'vs/platform/label/common/label'; import { TerminalSettingId } from 'vs/platform/terminal/common/terminal'; import { IWorkbenchContribution } from 'vs/workbench/common/contributions';


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

@ITerminalService terminalService: ITerminalService, @ITerminalEditorService terminalEditorService: ITerminalEditorService, @ITerminalGroupService terminalGroupService: ITerminalGroupService, <del> @IConfigurationService configurationService: IConfigurationService, @IContextKeyService contextKeyService: IContextKeyService </del> <ins> @IConfigurationService configurationService: IConfigurationService </ins> ) { super();


Question:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

} }); <del> const viewKey = new Set<string>(); viewKey.add('focusedView'); </del> TabFocus.setTabFocusMode(configurationService.getValue('editor.tabFocusMode'), TabFocusContext.Editor); TabFocus.setTabFocusMode(configurationService.getValue(TerminalSettingId.TabFocusMode), TabFocusContext.Terminal); <del> this._register(contextKeyService.onDidChangeContext((c) => { if (c.affectsSome(viewKey)) { if (contextKeyService.getContextKeyValue('focusedView') === 'terminal') { TabFocus.setTabFocusMode(configurationService.getValue(TerminalSettingId.TabFocusMode), TabFocusContext.Terminal); } else { TabFocus.setTabFocusMode(configurationService.getValue('editor.tabFocusMode'), TabFocusContext.Editor); } } })); </del> } }


Question:
has indicated that the diff inserted / modified audio cues are hard to differentiate and that the sounds are not as fast / singular toned as they should be
what do you think of this?
I agree with the suggestion. At least for me it is very difficult to identify the difference between the sounds used.
Sounds good -- will start on this asap.
I don't hear the cues as often anymore. I also noticed that when using up/down keys on the right diff editor, no audio cue shows up for a deleted section. Example with .gitignore file: Left: Right:
I can reproduce
it's getting to the line I expect it to (see logs) but no sound is produced - thoughts? https://user-

switch (changeType) { case ChangeType.Add: audioCueService.playAudioCue(AudioCue.diffLineInserted, true); <ins> break; </ins> case ChangeType.Delete: audioCueService.playAudioCue(AudioCue.diffLineDeleted, true); <ins> break; </ins> case ChangeType.Modify: audioCueService.playAudioCue(AudioCue.diffLineModified, true); <ins> break; </ins> } }


Question:
has indicated that the diff inserted / modified audio cues are hard to differentiate and that the sounds are not as fast / singular toned as they should be
what do you think of this?
I agree with the suggestion. At least for me it is very difficult to identify the difference between the sounds used.
Sounds good -- will start on this asap.
I don't hear the cues as often anymore. I also noticed that when using up/down keys on the right diff editor, no audio cue shows up for a deleted section. Example with .gitignore file: Left: Right:
I can reproduce
it's getting to the line I expect it to (see logs) but no sound is produced - thoughts? https://user-

const sound = this.sounds.get(url); if (sound) { sound.volume = this.getVolumeInPercent() / 100; <ins> sound.currentTime = 0; </ins> await sound.play(); } else { const playedSound = await playAudio(url, this.getVolumeInPercent() / 100);


Question:
<!-- 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: 1.75.1 OS Version: macOS 13 Steps to Reproduce: the following settings to : suggestions still show up: <img width="766" alt="image" src="https://user-"
what you are looking at is the hover. to disable that use this setting
Hi, I want to remove the three dots, disabling hovering doesn't help, these two settings , now they don't, a recent update broke that, please reopen this and take a look .
Oh, you mean "hint" diagnostics. Forwarding to for comment
Thanks for fowarding, I got the term from the : !

function areLanguageDiagnosticSettingsEqual(currentSettings: LanguageDiagnosticSettings, newSettings: LanguageDiagnosticSettings): boolean { return currentSettings.validate === newSettings.validate <del> && currentSettings.enableSuggestions && currentSettings.enableSuggestions; </del> <ins> && currentSettings.enableSuggestions === newSettings.enableSuggestions; </ins> } class DiagnosticSettings {


import { CancellationToken } from 'vs/base/common/cancellation'; import { FuzzyScore } from 'vs/base/common/filters'; import { Iterable } from 'vs/base/common/iterator'; <del> import { RefCountedDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, RefCountedDisposable } from 'vs/base/common/lifecycle'; </ins> import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; import { ICodeEditorService } from 'vs/editor/browser/services/codeEditorService'; import { EditorOption } from 'vs/editor/common/config/editorOptions';


} <del> export class SuggestInlineCompletions implements InlineCompletionsProvider<InlineCompletionResults> { </del> <ins> export class SuggestInlineCompletions extends Disposable implements InlineCompletionsProvider<InlineCompletionResults> { </ins> private _lastResult?: InlineCompletionResults;


@IClipboardService private readonly _clipboardService: IClipboardService, @ISuggestMemoryService private readonly _suggestMemoryService: ISuggestMemoryService, @ICodeEditorService private readonly _editorService: ICodeEditorService, <del> ) { } </del> <ins> ) { super(); this._store.add(_languageFeatureService.inlineCompletionsProvider.register('*', this)); } </ins> async provideInlineCompletions(model: ITextModel, position: Position, context: InlineCompletionContext, token: CancellationToken): Promise<InlineCompletionResults | undefined> {


test('Aggressive inline completions when typing within line #146948', async function () { <del> const completions: SuggestInlineCompletions = insta.createInstance(SuggestInlineCompletions); </del> <ins> const completions: SuggestInlineCompletions = disposables.add(insta.createInstance(SuggestInlineCompletions)); </ins> { // (1,3), end of word -> suggestions


}); test('Snippets show in inline suggestions even though they are turned off #175190', async function () { <del> const completions: SuggestInlineCompletions = insta.createInstance(SuggestInlineCompletions); </del> <ins> const completions: SuggestInlineCompletions = disposables.add(insta.createInstance(SuggestInlineCompletions)); </ins> { // unfiltered


Question:
With new API type was but that type isn't used anywhere and looks like a leftover. We should remove it before releasing stable.
fyi
My bad, I must have it and forgot to remove it.
Thanks for the quick turnaround

/** * Value-object describing what options formatting should use. */ <del> export interface SortingOptions { /** * Size of a tab in spaces. */ tabSize: number; /** * Prefer spaces over tabs. */ insertSpaces: boolean; /** * Signature for further properties. */ [key: string]: boolean | number | string; } /** * Value-object describing what options formatting should use. */ </del> export interface FormattingOptions { /**


Question: With Dark High Contrast theme, everything is clear except for warning and errors... Error is shown with an orange x: ! While warnings are exclamation mark in blaring red: ! I mean there's no two ways about it... RED is error, RED+certain amount of yellow(orange is fine) is warning.

export const editorErrorBorder = registerColor('editorError.border', { dark: null, light: null, hcDark: Color.fromHex('#E47777').transparent(0.8), hcLight: '#B5200D' }, nls.localize('errorBorder', 'Border color of error boxes in the editor.')); export const editorWarningBackground = registerColor('editorWarning.background', { dark: null, light: null, hcDark: null, hcLight: null }, nls.localize('editorWarning.background', 'Background color of warning text in the editor. The color must not be opaque so as not to hide underlying decorations.'), true); <del> export const editorWarningForeground = registerColor('editorWarning.foreground', { dark: '#CCA700', light: '#BF8803', hcDark: '#FFD37', hcLight: '#895503' }, nls.localize('editorWarning.foreground', 'Foreground color of warning squigglies in the editor.')); </del> <ins> export const editorWarningForeground = registerColor('editorWarning.foreground', { dark: '#CCA700', light: '#BF8803', hcDark: '#FFD370', hcLight: '#895503' }, nls.localize('editorWarning.foreground', 'Foreground color of warning squigglies in the editor.')); </ins> export const editorWarningBorder = registerColor('editorWarning.border', { dark: null, light: null, hcDark: Color.fromHex('#FFCC00').transparent(0.8), hcLight: '#' }, nls.localize('warningBorder', 'Border color of warning boxes in the editor.')); export const editorInfoBackground = registerColor('editorInfo.background', { dark: null, light: null, hcDark: null, hcLight: null }, nls.localize('editorInfo.background', 'Background color of info text in the editor. The color must not be opaque so as not to hide underlying decorations.'), true);


Question:
<!-- 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. --- VS Code Version: 1.76.0 OS Version: macOS 11.6.2 Version: 1.76.0 Commit: Date: 2023-03-01T10:23:45.993Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 20.6.0 Sandboxed: No Summary When creating a profile with a name such as "Typescript / Javascript", the following happens: When exporting as a Gist, no result dialog shows ("there was trouble" / "created profile successfully") and a validation error is outputted in the logs When exporting to a local file, the text after the last forward slash is set as the filename. With the above example, it'd be " " To reproduce: a profile: Settings cog -"Profile ([...])" the profile: Select "Export Profile..." -"Export" the "name the profile" step, enter a name with a forward slash in like so: "Typescript / Javascript" either method for exporting: gist or local Expected results: If you select local: a system save prompt with the name you entered pre-set in the filename field If you select gist: A success dialog with a link to the website prefilled with your config Actual results: If you select local: only the text after the last forward slash is in the filename field If you select gist: No dialog shows. The following error is in the "output" window, under "Window": I can only test this on a macOS device, I haven't tried this on a Windows or other Linux device and I feel like (with the area in mind - filesystems etc) these issues could manifest differently or not even be an issue there. I'm assuming validation on the inputbox for the name will be required because filesystems (and Gist? not sure) don't typically support forward slashes in file names. Thanks and if you're reading this, have a great weekend :)
Gists do no accept in the name. Replaced with .

try { const userDataProfilesExportState = disposables.add(this.instantiationService.createInstance(UserDataProfileExportState, this.userDataProfileService.currentProfile)); const barrier = new Barrier(); <del> const exportAction = new BarrierAction(barrier, new Action('export', localize('export', "Export"), undefined, true, () => { </del> <ins> const exportAction = new BarrierAction(barrier, new Action('export', localize('export', "Export"), undefined, true, async () => { </ins> exportAction.enabled = false; <del> return this.doExportProfile(userDataProfilesExportState); })); const closeAction = new BarrierAction(barrier, new Action('close', localize('close', "Close"))); </del> <ins> try { await this.doExportProfile(userDataProfilesExportState); } catch (error) { this.notificationService.error(error); throw error; } }), this.notificationService); const closeAction = new BarrierAction(barrier, new Action('close', localize('close', "Close")), this.notificationService); </ins> await this.showProfilePreviewView(EXPORT_PROFILE_PREVIEW_VIEW, userDataProfilesExportState.profile.name, exportAction, closeAction, true, userDataProfilesExportState); disposables.add(this.userDataProfileService.onDidChangeCurrentProfile(e => barrier.open())); await barrier.wait();


Question:
<!-- 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. --- VS Code Version: 1.76.0 OS Version: macOS 11.6.2 Version: 1.76.0 Commit: Date: 2023-03-01T10:23:45.993Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 20.6.0 Sandboxed: No Summary When creating a profile with a name such as "Typescript / Javascript", the following happens: When exporting as a Gist, no result dialog shows ("there was trouble" / "created profile successfully") and a validation error is outputted in the logs When exporting to a local file, the text after the last forward slash is set as the filename. With the above example, it'd be " " To reproduce: a profile: Settings cog -"Profile ([...])" the profile: Select "Export Profile..." -"Export" the "name the profile" step, enter a name with a forward slash in like so: "Typescript / Javascript" either method for exporting: gist or local Expected results: If you select local: a system save prompt with the name you entered pre-set in the filename field If you select gist: A success dialog with a link to the website prefilled with your config Actual results: If you select local: only the text after the last forward slash is in the filename field If you select gist: No dialog shows. The following error is in the "output" window, under "Window": I can only test this on a macOS device, I haven't tried this on a Windows or other Linux device and I feel like (with the area in mind - filesystems etc) these issues could manifest differently or not even be an issue there. I'm assuming validation on the inputbox for the name will be required because filesystems (and Gist? not sure) don't typically support forward slashes in file names. Thanks and if you're reading this, have a great weekend :)
Gists do no accept in the name. Replaced with .

if (!profileContentHandler) { return; } <del> const saveResult = await profileContentHandler.saveProfile(profile.name, JSON.stringify(profile), CancellationToken.None); </del> <ins> const saveResult = await profileContentHandler.saveProfile(profile.name.replace('/', '-'), JSON.stringify(profile), CancellationToken.None); </ins> if (!saveResult) { return; }