jiebi/CodeConvo huggingface dataset:
Code change:
} 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;

Related discussion:
text: 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.
Code change:
} 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;

Related discussion:
text: 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.
Code change:
} 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;

Related discussion:
text: 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?
Code change:
} 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;

Related discussion:
text: 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.
Code change:
group: 'navigation', isHiddenByDefault: true, }, <del> keybinding: { </del> <ins> keybinding: [{ </ins> primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.Enter, mac: { primary: KeyMod.WinCtrl | KeyCode.Enter, }, weight: KeybindingWeight.EditorContrib, <del> when: CONTEXT_IN_CHAT_SESSION } </del> <ins> when: ContextKeyExpr.and(CONTEXT_IN_CHAT_SESSION, CONTEXT_ACCESSIBILITY_MODE_ENABLED.negate()), }, { primary: KeyMod.CtrlCmd | KeyCode.Slash, mac: { primary: KeyMod.WinCtrl | KeyCode.Slash }, weight: KeybindingWeight.WorkbenchContrib, when: ContextKeyExpr.and(CONTEXT_IN_CHAT_SESSION, CONTEXT_ACCESSIBILITY_MODE_ENABLED), }] </ins> }); }

Related discussion:
text: is used in the inline chat widget to accept a suggestion is used in the accessible view to accept an inline completion suggestion There is no keybinding to insert the current chat code block suggestion at the current cursor location is used to submit a comment from within a comment widget suggested aligning these. what do you think of adding a default keybinding of for inserting the current chat code block at the current cursor location? I will change the inline completion suggestion acceptance in the accessible view to .
-- Did you mean ? I think can be used for submission. There is no issue with this key. Submitting pull request, for example, is also . However, when Accepting something, we may want to use for the consistency.
I was suggesting we align all of these to use rather than .
I don't think people will be in favor of to accept in the inline chat widget as that would break muscle memory.
-- FYI, the following keybinding is also :
I've refined the original content of this issue to reflect the ask. We shall see what people say.
Here is my summary: for submitting actions. Evidence: GitHub Pull Request uses this keybinding. Also, "Report Issue" under Help menu also adopts as its default keybinding for submitting issue content. for accepting or inserting suggestions. Evidence: already uses this keybinding. Also, Accessible View adapted this for accepting the current inline suggestion.
I think that's not a good keybinding and that Ctrl+Enter is way better because it's easier to reach, e.g on a DE/CH keyboard you need to press Shift+7 to get /
I am then not against unifying all the listed keybindings in favor of .
To verify: Focus an editor Enable screen reader mode Focus a chat code block Use and verify that the code is inserted in the editor at the current cursor position
Code change:
@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> {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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: Windows 11 OS Version: 1.75.1 Steps to Reproduce: Using the following settings: ! ! a typescript file within a method/function following gets output (might have to navigate through some of the suggestions) even though snippets are off: !
Thanks for the patience. I cannot reproduce, please share more of your settings that might influence this. Also share data in a copy-paste friendly way (text over images)
Here are the settings that I am using to reproduce (all extensions disabled ): Once typing and going to the 3rd suggestion, I get this as a suggestion: !
Thanks for clarifying, looks like we aren't passing the filter here:
I can't figure out how to get that ghost text to show up for suggestions to verify this. I've never seen that ghost text for anything but copilot completions Do I need a suggestion provider extension?
You are right. I made a refactoring after this fix and that broke this feature Thanks for the diligence on this one!
To verify, use the steps from Make sure no snippets completions are ghost-texted with and that they are when the setting is set accordingly
I still cannot get snippet completions to show up
You need to say what you are trying because I do see them working just fine <img width="922" alt="Screenshot 2024-01-26 at 18 14 32" src=""
This works correctly for me now, no snippets with , and they do show up without it.
Bang on.
Code change:
@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> {

Related discussion:
text: The whole point is that the -setting is honored also for ghost suggestions
: <img width="1792" alt="Screenshot 2024-01-26 at 9 19 47 AM" src=""
this is about ghost text, please see and the comment linked from there
there was a syntax error in my file, so the settings did not get applied. Now it works
Code change:
}; function getTarget() { <del> return document.getElementById('_target'); </del> <ins> return document.getElementById('_target');; </ins> }; const ipcRenderer = require('electron').ipcRenderer;

Related discussion:
text: I notice that when I edit our 1.9 release notes, the markdown preview seems to jump up and down all the time there is a change. Compared to 1.8 stable, this seemed to not happen.
Better, I still see flickering that it jumps up and down a little bit and the decoration to the left to show me the current edited location is also flickering. let me know if I should open a separate issue on that or if you think that is fixable.
The flicker should now be better than VSCode 1.8, but we can still do better. I've noticed the same sort of slight flicker on images in particular and on the current paragraph indicator as you noted. Please open another, lower priority issue so that we can track further improvements Thanks
Code change:
const isServerless = platform.isWeb && !accessor.get(IWorkbenchEnvironmentService).remoteAuthority; return ` ## Interactive Editor Playground <del> The core editor in VS Code is packed with features.  This page highlights a number of them and lets you interactively try them out through the use of a number of embedded editors.  For full details on the editor features for VS Code and more head over to our [documentation](command:workbench.action.openDocumentationUrl). </del> <ins> The core editor in VS Code is packed with features.  This page highlights a number of them and lets you interactively try them out through the use of a number of embedded editors.  For full details on the editor features for VS Code and more head over to our [documentation](https://code.visualstudio.com/docs). </ins> * [Multi-cursor Editing](#multi-cursor-editing) - block selection, select all occurrences, add additional cursors and more. * [IntelliSense](#intellisense) - get code assistance and parameter suggestions for your code and external modules.

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- 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: Version: 1.93.0-insider (user setup) Commit: Date: 2024-09-04T13:13:15.344Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0. OS Version: Windows 11 Insiders Steps to Reproduce: in the first paragraph doesn't appear to be a link, which I was surprised about: ! I hover over it, I see it's supposed to be a link, but clicking on it does nothing: ! The other docs links at the bottom of the playground appear correctly as links and do open when I click on them: !
This seems related to the bookmark issue we had in the release notes. The other bookmark links in the interactive playground don't work either.
Fixed the toc links. Need another fix for the documentation link too (which use command uris)
The Editor Playground is not showing at all anymore in the latest insiders. When selecting the Editor Playground menu item, a black editor comes up.
hm working from oss builds. Insiders, it seems like the error is:
Actually unrelated. Seems like a duplicate of and fixed by
Code change:
} } <del> private doGetChildren(node: IAsyncDataTreeNode<TInput, T>): Promise<Iterable<T>> { </del> <ins> private doGetChildren(node: IAsyncDataTreeNode<TInput, T>): Promise<Iterable<T>> | Iterable<T> { </ins> let result = this.refreshPromises.get(node); if (result) { return result; } <del> result = createCancelablePromise(async () => { const children = await this.dataSource.getChildren(node.element!); </del> <ins> const children = this.dataSource.getChildren(node.element!); if (isIterable(children)) { </ins> return this.processChildren(children); <del> }); this.refreshPromises.set(node, result); return result.finally(() => { this.refreshPromises.delete(node); }); </del> <ins> } else { result = createCancelablePromise(async () => this.processChildren(await children)); this.refreshPromises.set(node, result); return result.finally(() => { this.refreshPromises.delete(node); }); } </ins> } private _onDidChangeCollapseState({ node, deep }: ICollapseStateChangeEvent<IAsyncDataTreeNode<TInput, T> | null, any>): void {

Related discussion:
text: takes much longer to render with file nesting enabled. Impact is lessened by disabling file nest auto-expansions. is not significantly slower to render with nesting, though I have not collected proper numbers yet.
closedWith
takes a comparable amount of time to render with file nesting enabled, though there is a perceptible delay for both. However, I do also notice that the window becomes intermittently unresponsive after expanding , e.g. when scrolling in the explorer. Is this known?
Yeah, same thing happens with nesting disabled. There's an open issue somewhere for ways to reduce that (like streaming the dir contents).