Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass the function signature in the detail property of the completion item instead of the label #685

Open
ramya-rao-a opened this issue Oct 23, 2018 · 7 comments

Comments

@ramya-rao-a
Copy link

ramya-rao-a commented Oct 23, 2018

Based on the gif in the README and the snapshots in microsoft/vscode#29126 (comment), it looks like this extension is appending the function signature to the function name in the label of the completion item.

This makes the reading of the items hard, especially when the docs are expanded to the side (Hit Ctrl+Space to show/hide the docs once the suggest widget is open)

The CompletionItem has a property called detail. Most extensions use this property to pass the signature. Below is a typsescript example:

image

image

I understand the temptation to include the signature as part of the label. It allows the user to choose the right item from the list at a glance. But this is only possible when the function name is small and docs are collapsed. Else, it just adds noise

image

@fbricon
Copy link
Collaborator

fbricon commented Oct 23, 2018

would be less of an issue if microsoft/vscode#29757 was fixed.

Changing the signature format is probably going to be controversial. If we were to change anything, then I'd suggest you make it through a user preference. Feel free to provide a quality patch ;-)

@IAmHopp
Copy link

IAmHopp commented Oct 25, 2018

would be less of an issue if microsoft/vscode#29757 was fixed.

Maybe less of an issue, but an issue still, since it'd require scrolling to see the rest of the text, while @ramya-rao-a's proposal does not.

However, I don't think this truly is the solution. It makes perfect sense to include the method signature in the title property. The reason this is only useful when the method name is small [and sometimes not even then -- return type is also important and that's not entirely readable in the first result on the second screenshot] is because the widget is weirdly small. Personally, instead of working around it by adding scrollbars or segregating information that belongs together, eventually vscode should just address the fact that the widget as it is today is made to only display a strangely minimal amount of information horizontally -- and it would be beneficial for that to change.

@ramya-rao-a
Copy link
Author

Personally, instead of working around it by adding scrollbars or segregating information that belongs together, eventually vscode should just address the fact that the widget as it is today is made to only display a strangely minimal amount of information horizontally -- and it would be beneficial for that to change.

I believe thats where the doc section comes in i.e the part on the right side below which has the complete information whereas the left side has minimal information.

image

@IAmHopp
Copy link

IAmHopp commented Oct 31, 2018

Right, but I don't get why it only has minimal information in the first place. I don't get the upside. There is a clear, transparent reason why so many people in microsoft/vscode#29757 went through all the trouble of editing the workbench CSS (!) just to make it bigger. It could... Just be bigger. It actually solves the whole problem instead of working around it.

I get that if the title only shows minimal information, putting everything else in the detail page guarantees there's no information missing, but what also achieves that is adjusting the size of the widget so that it comfortably displays the information it's supposed to. What I meant above by segregating information is: if I'm trying to autocomplete a method? I want the method signature. It's how we identify methods. By their signature. It doesn't help putting part of the signature in the title and part of it in the detail. That just means I have to keep looking left and right as I move down the list. How is that better than just having a widget that can show the whole signature in the title? How is that easier?

It's not about shoving everything down in the title, by the way. The detail can still be very useful for complementary information, such as method documentation, maybe package information, whether it's overridden or not, there are plenty of options. But the signature, in my opinion, should be part of the title. And that widget should be allowed to be bigger.

@ramya-rao-a
Copy link
Author

ramya-rao-a commented Oct 31, 2018

We are not saying that we will never get around to changing the UI of the widget. If we were saying that, then microsoft/vscode#29757 would not be an open item, it would have been closed long ago.

It could... Just be bigger. It actually solves the whole problem instead of working around it.

Increasing the size will not solve the whole problem. There will always be method names or signatures that will be bigger. Which is why the guideline is to have just the method name in the title, and signatures in the detail part.

Horizontal scrollbars or re-sizable widget could solve whole problem. But none of our widgets have these features at the moment and therefore are not trivial.

Changing the signature format is probably going to be controversial. If we were to change anything, then I'd suggest you make it through a user preference.

I logged this issue only to bring about consistency with other language extensions and to ease the current problem until microsoft/vscode#29757 is solved. @fbricon is most welcome to close this if it is too controversial for Java users.

@fbricon
Copy link
Collaborator

fbricon commented Oct 31, 2018

As I said before, I'm open to displaying less information in the signature, provided this is driven by user preference.

@arash-bizcover
Copy link

microsoft/vscode#14165

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants