jiebi/CodeConvo huggingface dataset:
Code change:
export function makeKeyOptionalMessage(markerData: IMarkerData, useMessage: boolean): string { let result: string[] = [emptyString]; if (markerData.source) { <del> result.push(markerData.source.replace('¦', '¦')); </del> <ins> result.push(markerData.source.replace('¦', '¦')); </ins> } else { result.push(emptyString); } if (markerData.code) { if (typeof markerData.code === 'string') { <del> result.push(markerData.code.replace('¦', '¦')); </del> <ins> result.push(markerData.code.replace('¦', '¦')); </ins> } else { <del> result.push(markerData.code.value.replace('¦', '¦')); </del> <ins> result.push(markerData.code.value.replace('¦', '¦')); </ins> } } else { result.push(emptyString);

Related discussion:
text: The code in question looks like: This doesn't actually do anything, and is likely a bug. There are a few cases in .
Code change:
instantiationService.stub(IKeybindingService, new MockKeybindingService()); instantiationService.stub(INotebookCellStatusBarService, disposables.add(new NotebookCellStatusBarService())); instantiationService.stub(ICodeEditorService, disposables.add(new TestCodeEditorService(testThemeService))); <del> instantiationService.stub(IInlineChatService, instantiationService.createInstance(InlineChatServiceImpl)); </del> instantiationService.stub(INotebookCellOutlineProviderFactory, instantiationService.createInstance(NotebookCellOutlineProviderFactory)); instantiationService.stub(ILanguageDetectionService, new class MockLanguageDetectionService implements ILanguageDetectionService {

Related discussion:
text: There are some parts in notebook land that depend on . This service and its provider are deprecated and should be removed. As of today the following dependencies must be cleaned up first: , , The should be used instead, it will allow you to know if a agent per location exists or not
Code change:
"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "xterm": "5.2.0-beta.30", "xterm-addon-canvas": "0.4.0-beta.7", </del> <ins> "xterm": "5.2.0-beta.33", "xterm-addon-canvas": "0.4.0-beta.9", </ins> "xterm-addon-search": "0.11.0", "xterm-addon-serialize": "0.9.0", "xterm-addon-unicode11": "0.5.0", <del> "xterm-addon-webgl": "0.15.0-beta.7", "xterm-headless": "5.2.0-beta.30", </del> <ins> "xterm-addon-webgl": "0.15.0-beta.8", "xterm-headless": "5.2.0-beta.33", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --With the above settings in effect and a terminal open in the bottom panel: If the terminal has focus, the cursor blinks If the terminal doesn't have focus, then the cursor remains visible without blinking Unlike the block-shaped cursor, which becomes hollow when the terminal loses focus, the line-shaped cursor doesn't change appearance when the terminal loses focus; it merely stops blinking. This makes it hard to tell at a glance whether the terminal has focus. So that it's easier to tell whether the terminal has focus, I would like an option to customize how the line-shaped cursor appears in the terminal when it doesn't have focus. Possible options (not exhaustive): Hide the cursor altogether Keep it visible, but make it (say) 50% opacity Show the same hollow block that's used with the block-shaped cursor
I actually thought it showed the hollow block in this case, I think that makes the most sense
try try
We're going back on the decision made in and making unfocused show the rectangle regardless of cursor style. Discussion:
Code change:
const focusTracker = this._register(dom.trackFocus(this._stickyScrollWidget.getDomNode())); this._register(focusTracker.onDidBlur(_ => { const height = this._stickyScrollWidget.getDomNode().clientHeight; <del> if (height !== 0) { this._disposeFocusStickyScrollStore(); } else { // If the height is 0, then the blur has been caused by scrolling. In that case keep the focus on the sticky scroll. </del> <ins> // Suppose that the blurring is caused by scrolling, then keep the focus on the sticky scroll // This is determined by the fact that the height of the widget has become zero and there has been no position revealing if (this._positionRevealed === false && height === 0) { </ins> this._focusedStickyElementIndex = -1; this.focus(); <ins> } // In all other casees, dispose the focus on the sticky scroll else { this._disposeFocusStickyScrollStore(); </ins> } })); this._register(focusTracker.onDidFocus(_ => { this.focus(); })); this._register(this._createClickLinkGesture()); <ins> // Suppose that mouse down on the sticky scroll, then do not focus on the sticky scroll because this will be followed by the revealing of a position this._register(dom.addDisposableListener(this._stickyScrollWidget.getDomNode(), dom.EventType.MOUSE_DOWN, (e) => { this._onMouseDown = true; })); </ins> } get stickyScrollCandidateProvider(): IStickyLineCandidateProvider {

Related discussion:
text: Testing a Markdown file with headers up to H3, enable Sticky Scroll and scroll up and down in the editor. Stick Scroll a header leve and press . Try to scroll up and down with the arrow keys. Unclear where the cursor focus is. Try typing, the editor doesn't have focus Focus should should probably go to the editor on the selected header. That is the behavior with breadcrumb navigation
This is the general behavior of Sticky Scroll and also reproduces if you select a level via the mouse
Verified on OSS
Code change:
} private _layout(): void { <del> const height = Math.max(this._editor.getLayoutInfo().height / 4, 250); </del> <ins> const height = Math.max(this._editor.getLayoutInfo().height / 4, 250, ContentHoverWidget._lastDimensions.height); const width = Math.max(this._editor.getLayoutInfo().width * 0.66, 500, ContentHoverWidget._lastDimensions.width); </ins> const { fontSize, lineHeight } = this._editor.getOption(EditorOption.fontInfo); const contentsDomNode = this._hover.contentsDomNode; contentsDomNode.style.fontSize = `${fontSize}px`; contentsDomNode.style.lineHeight = `${lineHeight / fontSize}`; <del> this._setContentsDomNodeMaxDimensions(Math.max(this._editor.getLayoutInfo().width * 0.66, 500), height); </del> <ins> this._setContentsDomNodeMaxDimensions(width, height); </ins> } private _updateFont(): void {

Related discussion:
text: Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.
Code change:
"type": "string", "enum": [ "npm", <del> "yarn" </del> <ins> "yarn", "pnpm" </ins> ], "default": "npm", "description": "%config.npm.packageManager%"

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The [NPM support for VS Code built-in extension][extension] (which automatically detects NPM scripts and provides a UI to run them in the sidebar) has an settting. Currently, this setting only supports the options or . This means it won't work with the [pnpm package manager][pnpm]. Adding a option would be really helpful to users who use pnpm rather than npm or yarn. Both [vscode-eslint][] and [typescript-tslint-plugin][] also already support using pnpm as the preferred Node package manager. I personally use pnpm because its reduced disk space/bandwidth footprint and its architecture both work better for me. I've experimented with just overwriting the value in with , and ignoring the warning from the linter. This seems to work (on macOS), so I'm guessing it might be as simple as adding to the array here: I just don't understand the extensions well enough to be sure that's correct / enough to properly add pnpm. [extension]: [pnpm]: [vscode-eslint]: [typescript-tslint-plugin]: [source]:
Code change:
import { Repl, ClearReplAction } from 'vs/workbench/parts/debug/electron-browser/repl'; import { DebugQuickOpenHandler } from 'vs/workbench/parts/debug/browser/debugQuickOpen'; import { DebugStatus } from 'vs/workbench/parts/debug/browser/debugStatus'; <del> import { LifecyclePhase, ILifecycleService } from 'vs/platform/lifecycle/common/lifecycle'; </del> <ins> import { LifecyclePhase } from 'vs/platform/lifecycle/common/lifecycle'; </ins> import { launchSchemaId } from 'vs/workbench/services/configuration/common/configuration'; import { IEditorGroupsService } from 'vs/workbench/services/group/common/editorGroupsService'; import { LoadedScriptsView } from 'vs/workbench/parts/debug/browser/loadedScriptsView'; import { TOGGLE_LOG_POINT_ID, TOGGLE_CONDITIONAL_BREAKPOINT_ID, TOGGLE_BREAKPOINT_ID } from 'vs/workbench/parts/debug/browser/debugEditorActions'; <del> import { INotificationService } from 'vs/platform/notification/common/notification'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; </del> class OpenDebugViewletAction extends ShowViewletAction { public static readonly ID = VIEWLET_ID;

Related discussion:
text: Somehow I missed the change in the and only now found it out. What I do not udnerstand is why we need all this code? I think this handler should be removed and the action should be called like it was done previously. Code pointer: It would be great if we could tackle this in December. Thanks
The reason for this code change was that creates a handler for command that passes no arguments to the action: So instead I used with a handler that would forward the argument. It looks like there are other debug commands registered in this way in , so I think moving the code for startDebug there makes sense. The handlers there are shorter and less generic, I'll see if rewriting the startDebug one that way causes any issues
what you need is calling the start debug with a configuration, and I believe we already have a way for doing this. can you please provide a pointer to where you are already calling start debug with a configuration. are you calling start debug from the main side or where from exactly? I can also look into this. You can just let me know how to verify that I did not break your scenario.
The extension API's implementation passes a debug configuration to the debug service's startDebugging here:
I'm trying to start debugging from the process explorer. Since it's a separate browser window, it doesn't have access to the debug workbench service, and it's also not an extension, so it can't leverage the extension API for starting debugging. Currently, the process explorer window sends an IPC message back to the issue service in the main process. This then sends an IPC message to the main renderer process to run the debug start command: The path is also used by the native menu to trigger commands from the main process.
ok got it. So the best way it seems is to what you have done going via the action. Can you try to clean up the handler. And if that does not work I can look into an alternative solution.
Sure, I'll work on cleaning up the handler today
Code change:
.monaco-editor .inline-folded:after { color: grey; margin: 0.1em 0.2em 0 0.2em; <del> content: "⋯"; </del> <ins> content: "22EF"; /* ellipses unicode character */ </ins> display: inline; line-height: 1em; cursor: pointer;

Related discussion:
text: Issue Type: <bBug</bFold a region and observe it. Unfortunately this went away after a window reload: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-23T05:27:08.615Z) OS version: Darwin arm64 21.4.0 Restricted Mode: No <!-- generated by issue reporter --
There haven't been any changes from mein that area recently. Likely a Chromium glitch. Please reopen if you have it reproducible.
I still don't know why this happens sometimes, but it shows up regularly. In the dev tools it shows that chromium has loaded the stylesheet in a wrongly encoded way. I hope to avoid this by escaping the ellipses unicode character.
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ .monaco-editor .resizable-widget { z-index: 40; display: block; } </ins>

Related discussion:
text: When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route.
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ .monaco-editor .resizable-widget { z-index: 40; display: block; } </ins>

Related discussion:
text: The suggested widths above were a bit much for me, so I settled on the following values for now:
What is preventing the devs from providing a configuration option for this? This issue has been open for almost 2 years, and it bugs me on a daily basis. Would love to see it fixed.
(since you seem like the most relevant person to ping) is anything likely to be done about this?
I would love to hear an explanation from devs too. What are the difficulties of implementing this? I imagine it's settings a dynamic max-width and adding some more lines to add it in Settings. Are there other design blockers?
Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.
Assigned to and as I remember we are going to have some UX improvements for editor tooltips and so on.
maybe now is the time to take this on? current iteration tries to solve parameter hints ux and this is not that much different
! I employed CSS and put together full instructions: [Custom CSS and JS Loader extension][1] macOS VS Code: VS Code Insiders: Linux: : [1]: Restart VSCode Ignore "VSCode is corrupt" error You can choose to suppress this notice forever Run command "Reload Custom CSS and JS"
just as a disclaimer, if anyone modifies the CSS/JS of the app, it comes up at “corrupted” in diagnostic checks, and you’ll typically get pushback if you report issues and include diagnostic information. Or, at least, I received pushback when I had custom CSS/JS enabled, and wouldn’t receive help until I turned it off (even though it was harmless/not related to the issue I was having). While this is indeed an okay workaround, we should just keep making our voices heard so that this is natively supported.
100% agree. This is just a workaround. It's hard enough to read TypeScript lint as it is! :)
Currenlty using VSCode 1.30.2, followed instructions step by step, but it's not working. I don't even get the VSCode corrupt error. I'm running Windows 10 (V.1803). Edit: It was my mistake. For anyone who's having trouble, make sure to run Enable Custom CSS and JS from the command palette. Simply restarting won't work.
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ .monaco-editor .resizable-widget { z-index: 40; display: block; } </ins>

Related discussion:
text: This issue seems to be fixed in 1.32.0-insider (1.32.0-insider) . I hope this is an intended behavior. I want to thank the developers.
This change is related to . I confirmed that the max width of is still small as mentioned above. <img width="867" alt="2019-02-22 17 06 19" src="https://user-"
Update: in , only the hovers for problems and the hovers with code blocks become to have larger width. Others have smaller width.
Hello there,your solution is great,but I want to ask how to get rid of the word at the title.As sort of OCD,sufferring from that. thx a lot!
This extension was created specifically for solving this:
This has been a long standing annoyance, with an issue that's like 2 and a half year ago. It shouldn't take much effort to have a config property that overrides the width/height of the tooltip, surely? Like, 10 mins of effort? <img width="525" alt="Screen Shot 2019-07-18 at 6 41 15 PM" src="https://user-"
if it's really 10 mins of effort, then I'm sure you can submit a PR for this? I definitely can't do this in anywhere close to 10 mins, so it would be much appreciated!
Seriously, I want instead of this: ! At least something like this (with syntax highlighting it will be even better): !
There's already been a PR. I really don't understand this. I figure most VScode devs develop VScode in VScode, are they comfortable with the current state?
fyi, it would be great if the hover could be resized
How is this issue 4 years old and such a basic thing still isn't implemented?
Is there any word on whether we could see this soon? The suggestion widget has had resizing enabled since v1.51 in October, 2020. Is this tooltip widget considerably harder to add this feature for or are there additional considerations to be made? Whether it's a click to resize, or a manual adjustment in settings, could we have an update on the status of this addition? Opening new editor tabs just to properly read code annotations for some more descriptive components on my large monitors does feel like an unnecessary extra step.
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ .monaco-editor .resizable-widget { z-index: 40; display: block; } </ins>

Related discussion:
text: might be very related and close to what you did here:
Hi, Instead of configuring the max width as the title says, could the tooltip hover be resizable ? (Also check for more info on what was done with the suggest widget)
It's sad to see that it's still not a thing.. I would really like to adjust the height of hover description tooltips.. The big brother Visual Studio does a much better job already. Let VS Code catch up a little..
another possible view for this issue
It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!
"Excuse me, it's 2023"
This one will be my favorite. Copilot suggestions and TS errors just can't be seen in this tooltip. It's time to fix it.
If this is still open and no one is looking at it, I'll take a crack at it. Feel free to assign it to me if that's alright.
Hey all, thank you for your patience. A PR has been made which is currently under work but nearing its completion. You may find it here: Once this PR is merged, you will be able to resize content hovers within Insiders.
Would you add "Reset Hover Widget Size" command in Command Palette? Like we have for suggest widget: "Reset Suggest Widget Size". It would be good if we could reset the size to the initial one.
Thank you very much. 1 Is it correct, that this would not stay across different sessions? 2 The default max width is very small, is there any consideration, of increasing that?
Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?
Hi if is is decided that the hover widget size should be configurable, there will be a command to clear the persisted sizes. This feature is still under discussion. Hi depending on the implementation, it is possible that the persisted sizes are persisted or not across different sessions. This is still under discussion. Currently the implementation is such that the maximum natural width is the same as before. Hi the current implementation does not provide this functionality. This could be addressed in a separate issue as it is related to the usage of the hover widget by extensions. The current PR that is worked on is the following:
Thanks a lot.