Make the documentation of completionItem larger

[tamuratak]

This is a PR to make the documentation of completionItem larger, which solves #14165 along with commits by @sandy081 solving #67076.

Before:

After:

At various positions:

[msftclas]

All CLA requirements met.

[tamuratak]

I found that this PR sovles #29126 too.

[Astrantia]

@sandy081 @joaomoreno Why not merge this for the next release?

[joaomoreno]

Looks good, but I would put this behind a setting and leave the default as is.

[tamuratak]

I would like to resolve the conflict if needed.

[joaomoreno]

Sure, go ahead 👍

[joaomoreno]

Don't forget this:

Looks good, but I would put this behind a setting and leave the default as is.

[tamuratak]

With vs/base/common/marked/marked, the maximum length of lines in code blocks is used to set the width of details if they exist. If not, the width is set 500px when this feature is enabled. When it is disabled, the width is set 330px.

Enabled:

Disabled:

@joaomoreno, fixed reacting to the setting change. Fixed the size of No suggestions.

[MOZGIII]

This might not be perfect as it is, however it definitely solves a pain point if the screenshots represent the reality. What if this is merged in as is, and then polished to automatically adapt to the size of the code later? It looks like users can switch to this new mode only if they want to, so this should be good enough for now.

[awulkan]

This looks good enough to me for now. Right now the documentation window is barely readable in a lot of cases, and It'd be sad to if a potential solution was stalled for years because it's not 100% perfect. It's better than what we currently have, and I believe it can be improved through incremental updates later on.

[wompeter]

These tiny popup windows have been a major usability issue for literally years, with people resorting to hacking the CSS and re-hacking it every update. I can't believe the reluctance to deal with the problem when there are solutions like this waiting to go.

[jrieken]

I think we have been pretty clear that the approach of two static sizes (large and not so large) is not what we want. We are looking for dynamic sizing that tries to fit the contents of the suggestion details widget, actually we try to have the same for hovers as well.

[tamuratak]

I heard it for the first time.

I think we have been pretty clear that the approach of two static sizes (large and not so large) is not what we want.

Do you mean that you have started implementing a dynamic sizing suggestion widget? Can I try it on a certain branch?

We are looking for dynamic sizing that tries to fit the contents of the suggestion details widget, actually we try to have the same for hovers as well.

[MOZGIII]

I think we have been pretty clear that the approach of two static sizes (large and not so large) is not what we want. We are looking for dynamic sizing that tries to fit the contents of the suggestion details widget, actually we try to have the same for hovers as well.

@jrieken, could you elaborate more on the desired approach? Or link us to a more in-depth discussion on the matter?

[tamuratak]

@jrieken in the following gif, for example, are you saying that the width of details should shrink to the actual length of inside texts if they are short?

However, if the width of suggestions details changes too dynamically, it will annoy users.

Moreover, when the width of suggestions changes dynamically, it is difficult to determine the correct position of it. In some cases, we have to change the position dynamically to prevent it going out of the window. And, it will annoy users.

[wompeter]

I think we have been pretty clear that the approach of two static sizes (large and not so large) is not what we want. We are looking for dynamic sizing that tries to fit the contents of the suggestion details widget, actually we try to have the same for hovers as well.

Is anyone actually looking though? Because this issue has been open in various forms since at least 2016.
#14165

Debugging in vscode is so painful because of this.