jiebi/CodeConvo huggingface dataset:
Code change:
} .monaco-hover .markdown-hover > .hover-contents:not(.code-hover-contents) { <del> max-width: 500px; </del> word-wrap: break-word; }

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:
} .monaco-hover .markdown-hover > .hover-contents:not(.code-hover-contents) { <del> max-width: 500px; </del> word-wrap: break-word; }

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:
} .monaco-hover .markdown-hover > .hover-contents:not(.code-hover-contents) { <del> max-width: 500px; </del> word-wrap: break-word; }

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.
Code change:
} .monaco-hover .markdown-hover > .hover-contents:not(.code-hover-contents) { <del> max-width: 500px; </del> word-wrap: break-word; }

Related discussion:
text: And do you consider increasing the default size, that is unfitting to most real world scenarios? The windows is so small, that I feel the need to increase it even on my WXGA Laptop.
Hey all, thank you for the patience. A PR has been merged in order to make the content hover resizable. The change should be visible in tomorrow's VS Code insiders version and in the next stable release which will happen in the coming two weeks. There currently is no mechanism to save the content hover - we are discussing how best to approach it. You may track the issue on persisting the hover content here: we are currently not thinking about increasing the default maximum size. However it is possible that we implement the persisting mechanism as follows: when you increase the content hover size to a specific size, this size is persisted, and it is applied as maximum default size on the next hover appearances. This potential implementation is still under discussion by our team.
Just want to say thank you you seem to have been tackling a lot of these high-level nitpicks that have been in the VSCode backlog for years, and for that I am very appreciative.
I can't find a command to clear/reset hover widget size, is this has been ?
Hi currently the command does not exist because a persisting mechanism has not been put into place as of yet. It will appear when the latter is .
Oh okay, thanks a lot
Code change:
} // Open based on config <del> const { windows: usedWindows, filesOpenedInWindow } = await this.doOpen(openConfig, workspacesToOpen, foldersToOpen, emptyWindowsWithBackupsToRestore, emptyToOpen, filesToOpen, foldersToAdd); </del> <ins> const { windows: usedWindows, filesOpenedInWindow } = await this.doOpen(openConfig, workspacesToOpen, foldersToOpen, emptyWindowsWithBackupsToRestore, openOneEmptyWindow, filesToOpen, foldersToAdd); </ins> <del> this.logService.trace(`windowsManager#open used window count ${usedWindows.length} (workspacesToOpen: ${workspacesToOpen.length}, foldersToOpen: ${foldersToOpen.length}, emptyToRestore: ${emptyWindowsWithBackupsToRestore.length}, emptyToOpen: ${emptyToOpen})`); </del> <ins> this.logService.trace(`windowsManager#open used window count ${usedWindows.length} (workspacesToOpen: ${workspacesToOpen.length}, foldersToOpen: ${foldersToOpen.length}, emptyToRestore: ${emptyWindowsWithBackupsToRestore.length}, openOneEmptyWindow: ${openOneEmptyWindow})`); </ins> // Make sure to pass focus to the most relevant of the windows if we open multiple if (usedWindows.length > 1) {

Related discussion:
text: Steps to Reproduce: to 1 window on a folder open the command line run = only the folder opens, but not an empty window I would expect here 2 windows to open, one is the folder and one the empty window since no argument was given to open any folder or file.
Code change:
/usr/share/@@NAME@@/ /usr/share/applications/@@NAME@@.desktop <ins> /usr/share/applications/@@NAME@@-url-handler.desktop </ins> /usr/share/pixmaps/@@NAME@@.png

Related discussion:
text: This may be useful as a hint: Please, take a two minutes to look into source, it may work only for :
I think adding a desktop file with that launches VS Code with is what's needed to implement this.
nice relevant gist:
VS Code has native support for opening it's own URL scheme via the hidden argument, I don't think there is a need for wrapper script shenanigans. I'm going to submit a PR.
I've not checked too far into it (Just subscribed to this to keep up to date) but the wrapper script is probably there because in the standard would include the "vscode://" prefix.
That's what should happen, that's what handles. :smiley: You can test if you like. Alternatively you can test this (Which is what the PR adds): For OSS: For release version: Drop it into or and run on that directory.
Code change:
import { IEditorGroupsService, IEditorGroup, GroupDirection, GroupLocation, GroupsOrder, preferredSideBySideGroupDirection, EditorGroupLayout } from 'vs/workbench/services/group/common/editorGroupsService'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <del> import { CommandsRegistry } from 'vs/platform/commands/common/commands'; </del> <ins> import { CommandsRegistry, ICommandHandler } from 'vs/platform/commands/common/commands'; </ins> import { MenuRegistry, MenuId } from 'vs/platform/actions/common/actions'; export const CLOSE_SAVED_EDITORS_COMMAND_ID = 'workbench.action.closeUnmodifiedEditors';

Related discussion:
text: I am forming an openEditorAtIndex command using the following syntax: '' + index 1-9 work correctly (and are default keybindings already). Would it be possible to add support for any index? I currently need to use this command if <= 9 and if 9, I have to go to index 9 and then next count - 9 times to get to the desired pane with a risk of wrapping around
trying to understand the scenario here, I do not think it makes sense for VSCode to introduce commands for more indices because this number is pretty much unlimited. Can we have another command that just goes to the next index, from the current one and you could use that instead? E.g. does it work if you use ?
Lines 55 - 89 are what I use to be able to go to any tab My case here is what I am trying to avoid Ideally I could do and never think twice about it The problem with using nextEditorInGroup is that I have no way of knowing the max editor number index, so if I say go to tab 10 and there are only 8 tabs, the current logic will try to go to tab 9 with the absolute exposed command, then use a nextEditorInGroup command.
that switch-case statement looks quite horrible, an alternative would be for the workbench to expose a command where you just pass the index as argument into. We already have that for other commands, e.g. see the "move editor command" () Would that be better?
That would work for me too! It is not very urgent since I don't think people navigate to tabs they can't see very often but for completeness it would be nice! Thanks!
Great. I would accept a reasonable small PR on this feature request.
I'll try to write a reasonable small PR for this :)
landed, thanks to
Some steps so I do not have to read the whole discussion? What command with what arguments should do what now?
here you go: write an extension that executes and verify the tab at that index opens.
Works nicely. Though the counting starts from - might be a bit confusing.
Ah yeah good point, but I think that is fine.
Code change:
} if (completion.command) { <del> await this._commandService .executeCommand(completion.command.id, ...(completion.command.arguments || [])) .then(undefined, onUnexpectedExternalError); </del> <ins> // Make sure the completion list will not be disposed. completion.source.addRef(); </ins> } <ins> // Reset before invoking the command, since the command might cause a follow up trigger. </ins> transaction(tx => { this._source.clear(tx); // Potentially, isActive will get set back to true by the typing or accept inline suggest event // if automatic inline suggestions are enabled. this._isActive.set(false, tx); }); <ins> if (completion.command) { await this._commandService .executeCommand(completion.command.id, ...(completion.command.arguments || [])) .then(undefined, onUnexpectedExternalError); completion.source.removeRef(); } </ins> } <del> public acceptNextWord(editor: ICodeEditor): void { this._acceptNext(editor, (pos, text) => { </del> <ins> public async acceptNextWord(editor: ICodeEditor): Promise<void> { await this._acceptNext(editor, (pos, text) => { </ins> const langId = this.textModel.getLanguageIdAtPosition(pos.lineNumber, pos.column); const config = this._languageConfigurationService.getLanguageConfiguration(langId); const wordRegExp = new RegExp(config.wordDefinition.source, config.wordDefinition.flags.replace('g', ''));

Related discussion:
text: One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Code change:
"pickerGroup.border": "#749351", "list.activeSelectionForeground": "#6c6c6c", "list.focusBackground": "#CADEB9", <ins> "list.hoverBackground": "#e0e0e0", </ins> "list.activeSelectionBackground": "#c4d9b1", "list.inactiveSelectionBackground": "#d3dbcd", "list.highlightForeground": "#9769dc",

Related discussion:
text: Light themes have relatively low contrast for foreground and hover colors. ideally we do not need to create a new color. Either we can tweak the default list colors which are used for quick pick , SelectBox, Explorer et cetera. Light Default: ! Bad Hover contrast: ! I suggest we increase the contrast for the default listHoverBackground applicable to all users. For the foreground color we could make this slightly darker again for the default. I don't see why we would create new colors either, I think whatever is good for selectBox should be the same and good for the quick pick Tagging this "under discussion" hopefully that is correct.
I finally figured out the listFocusForeground has no default, it's inherited from Monaco-shell. If we define it and listFocusHover in light-defaults we won't create any other colors. Screenshot does not do justice to foreground, you probably want to try it on your own machines. Let me know what you guys think. Below light+ with foreground, hover darkened: foreground === originally hover === # !
can you make a PR for me to try out your suggested color change?
Code change:
if (!Types.isString(info.command)) { missingAttribute('command'); } <del> return this.commandService.executeCommand<string>(info.command, info.args).then(result => { </del> <ins> return this.userInputAccessQueue.queue(() => this.commandService.executeCommand<string>(info.command, info.args)).then(result => { </ins> if (typeof result === 'string' || Types.isUndefinedOrNull(result)) { return result; }

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: 1.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.
Code change:
if (!Types.isString(info.command)) { missingAttribute('command'); } <del> return this.commandService.executeCommand<string>(info.command, info.args).then(result => { </del> <ins> return this.userInputAccessQueue.queue(() => this.commandService.executeCommand<string>(info.command, info.args)).then(result => { </ins> if (typeof result === 'string' || Types.isUndefinedOrNull(result)) { return result; }

Related discussion:
text: I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.