Configure tooltip max width

[OliverJAsh]

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.

[OliverJAsh]

I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!

[maxhoffmann]

Errors are quite unreadable if the width does not adapt to the font size.

[rakkarage]

it would be nice if the tip used the available space instead of wrapping at an arbitrary point
in c# too

[rakkarage]

[anowell]

Same problem using rust's language server.

[crucialfelix]

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.

[rakkarage]

[Tiedye]

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.

[Aggror]

Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well.

[MikhailArkhipov]

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.

[rakkarage]

[KaelWD]

Someone say long type signatures?

[ShenHongFei]

Here is a workaround by hacking the file "C:\Program Files\Microsoft VS Code\resources\app\out\vs\workbench\workbench.main.css"

    /* suggest-widget size */
        .monaco-editor .suggest-widget.docs-side {
            width: 1600px;
        }
        .monaco-editor .suggest-widget.docs-side > .details {
            width: 70%;
            max-height: 800px !important;
        }
        .monaco-editor .suggest-widget.docs-side > .tree {
            width: 30%;
            float: left;
        }
        
    /* parameter-hints-widget */
        .editor-widget.parameter-hints-widget.visible {
            max-height: 800px !important;
        }
        .monaco-editor .parameter-hints-widget > .wrapper {
            max-width: 1600px;
        }

    /* editor-hover */
        .monaco-editor-hover .monaco-editor-hover-content {
            max-width: 1600px;
        }

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)

[7sharp9]

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.

[macintacos]

Instead of hacking the CSS directly as @ShenHongFei mentioned above, I recommend using the Custom CSS and JS Loader extension 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 dotfiles 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. The suggested widths above were a bit much for me, so I settled on the following values for now:

/* suggest-widget size */

.monaco-editor .suggest-widget.docs-side {
  width: 1000px;
}

.monaco-editor .suggest-widget.docs-side > .details {
  width: 60%;
  max-height: 800px !important;
}

.monaco-editor .suggest-widget.docs-side > .tree {
  width: 30%;
  float: left;
}

/* parameter-hints-widget */

.editor-widget.parameter-hints-widget.visible {
  max-height: 800px !important;
}

.monaco-editor .parameter-hints-widget > .wrapper {
  max-width: 1000px;
}

/* editor-hover */

.monaco-editor-hover .monaco-editor-hover-content {
  max-width: 1000px;
}

[joealden]

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.

[tecosaur]

@roblourens (since you seem like the most relevant person to ping) is anything likely to be done about this?

[Astrantia]

@roblourens 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?

[Astrantia]

@rebornix Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.

[js1m]

It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!

[TFLXX]

"Excuse me, it's 2023" 🙂

[a-saven]

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.

[ryneandal]

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.

[aiday-mar]

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: #176744. Once this PR is merged, you will be able to resize content hovers within Insiders.

[svipas]

@aiday-mar 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.

[ShalokShalom]

@aiday-mar 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?

[MarvellousLunatic]

Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?

[aiday-mar]

Hi @svipas, 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 @ShalokShalom, 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 @MarvellousLunatic, 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: #178811

[ShalokShalom]

Thanks a lot. 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.

[aiday-mar]

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: #185743

@ShalokShalom 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.

[macintacos]

Just want to say thank you @aiday-mar, 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.

[svipas]

@aiday-mar I can't find a command to clear/reset hover widget size, is this has been added?

[aiday-mar]

Hi @svipas, 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 added.

[svipas]

@aiday-mar Oh okay, thanks a lot 👍