detailedLabelSupport not correctly implemented

[ryuukk]

Describe the bug

A screenshot worth more than words:

actual:

expected: (vscode)

To Reproduce

Use D's LSP according to the documentation

https://github.com/Pure-D/serve-d/

https://lsp.sublimetext.io/language_servers/#d

Expected behavior

with detailedLabelSupport, i expect each completion item to properly strip the funciton parameters, so it doesn't show the item label twice..

Screenshots

please refer to the 1st block above

Environment (please complete the following information):

• OS: arch linux
• Sublime Text version: 4126
• LSP version: 1.14
• Language servers used: D

[jfcherng]

There is no feasible solution. With ST's API, things you can fill in are trigger, annotation and details.

Related discussion

• https://discord.com/channels/280102180189634562/645268178397560865/893676807616884789

[ryuukk]

Oh i see, is it being looked at by the sublime text developpers?

[predragnikolic]

I am looking at the image for the expect behavior
and IMO displaying that much info in the autocomplete panel is distracting.

For me the LSP signature popup is used to show the parameters for a given function.

Is it helpful to see a pretty wide autocomplete popup with a bunch of information?
And if so please emphasize what information is really important.

[ryuukk]

@predragnikolic

showing all the lines isn't the point of the feature, let's ignore it for the moment (note that it is the case already for ST, it shows all the lines already with duplicate info)

it's the fact that no information is duplicated anymore

before:

create_texture --------------------------- Texture2D create_texture(uint....)

why is create_texture displayed twice?

after:

create_texture (uint...) --------------------------- Texture2D

There is less confusing, and the duplication of information is no more, shorter, and less distraction

--

Then for showing all the lines at once, it could be an option "show_details_for_all_items": "true|false"

[jwortmann]

1. Are you sure that the D server has the completionProvider.completionItem.labelDetailsSupport capability?
   I think this capability was renamed from detailedLabelSupport, so if the server still expects the old name, it may not send the CompletionItemLabelDetails at all to this client. An excerpt from the log panel with the payload when triggering autocompletions would reveal if that is the case.

   If you look at the code

   LSP/plugin/core/views.py

   Line 884 in f1e96dc

   st_annotation = (item.get("detail") or "").replace('\n', ' ')

   you can see that the only thing this client puts into the "annotation" field is CompletionItem.detail, but not CompletionItem.labelDetails.detail. It seems to be the case that the D server just puts everything into CompletionItem.detail here when it communicates with this client.
   The information from CompletionItemLabelDetails is only used for the "details" area at the bottom of the autocomplete popup:

   LSP/plugin/core/views.py

   Lines 889 to 905 in f1e96dc

   	if lsp_label_details:
   	if st_details:
   	st_details += " | "
   	lsp_label_detail = lsp_label_details.get("detail")
   	lsp_label_description = lsp_label_details.get("description")
   	st_details += "<p>"
   	# `label` should be rendered most prominent.
   	st_details += _wrap_in_tags("b", lsp_label)
   	if isinstance(lsp_label_detail, str):
   	# `detail` should be rendered less prominent than `label`.
   	# The string is appended directly after `label`, with no additional white space applied.
   	st_details += html.escape(lsp_label_detail)
   	if isinstance(lsp_label_description, str):
   	# `description` should be rendered less prominent than `detail`.
   	# Additional separation is added.
   	st_details += " - {}".format(_wrap_in_tags("i", lsp_label_description))
   	st_details += "</p>"

2. As it was already pointed out above, your suggestion

   create_texture (uint...) --------------------------- Texture2D

   is currently not possible with the ST API. If the additional details text is put into "trigger", then it would also be used for filtering of the items while typing, which probably would make the autocompletion behavior really bad.

3. Note that even VSCode does it a bit wrong; according to the LSP specs, CompletionItemLabelDetails.detail should be

   rendered less prominently directly after label, without any spacing.

   So it ideally should be create_texture(uint...), not create_texture (uint...)

[ryuukk]

1. i guess so, otherwise it wouldn't work on vscode?
2. vscode have 2 thing, label, so it show the text, and insertText, that's what get put instead of the label https://github.com/Pure-D/serve-d/blob/84094fade433f3d52e43c5296d20af53b102ffdd/source/served/commands/complete.d#L1197-L1219
3. i think the spacing was done intentionally by the D server https://github.com/Pure-D/serve-d/blob/84094fade433f3d52e43c5296d20af53b102ffdd/source/served/commands/complete.d#L1073

[jwortmann]

1. i guess so, otherwise it wouldn't work on vscode?

Yes, but I meant that maybe the D server expects detailedLabelSupport instead of labelDetailsSupport as a client capability, and perhaps VSCode also uses the old capability name for backwards compatibility or so. Anyway, you can test it if you set "log_server": ["panel"] in the LSP settings, then use "LSP: Toggle Log Panel" from the command palette and look for the server response after textDocument/completion. Then you can see if it contains "labelDetails" or not (I assume it doesn't).

2. vscode have 2 thing, label, so it show the text, and insertText, that's what get put instead of the label https://github.com/Pure-D/serve-d/blob/84094fade433f3d52e43c5296d20af53b102ffdd/source/served/commands/complete.d#L1197-L1219

Sublime LSP also supports and uses insertText. The point is that the "trigger" field is used for filtering. For example if you type foo, then do you want to see a completion item for the following?

3. i think the spacing was done intentionally by the D server https://github.com/Pure-D/serve-d/blob/84094fade433f3d52e43c5296d20af53b102ffdd/source/served/commands/complete.d#L1073

OK, then the screenshot from VSCode makes sense.

[ryuukk]

@jwortmann

{
	'kind': 3,
	'data': None,
	'label': 'create_texture',
	'labelDetails': {
		'description': 'Texture2D',
		'detail': ' (uint width, uint height, ubyte* ptr, PixelFormat format = PixelFormat.Rgba)'
	},
	'sortText': '2_4_Texture2D create_texture(uint width, uint height, ubyte* ptr, PixelFormat format = PixelFormat.Rgba)',
	'detail': 'Texture2D create_texture(uint width, uint height, ubyte* ptr, PixelFormat format = PixelFormat.Rgba)'
}

[jwortmann]

Maybe LSP should favor labelDetails.description, if it exists, over detail for the "annotation" field, and don't show it in the "details" area at the bottom then? I think the descriptions of the fields in the LSP specs are written in a way that doesn't consider having an additional panel area at the bottom.

     if isinstance(lsp_label_description, str): 
         # `description` should be rendered less prominent than `detail`. 
         # Additional separation is added. 
-        st_details += " - {}".format(_wrap_in_tags("i", lsp_label_description))
+        st_annotation = lsp_label_description.replace('\n', ' ')
     st_details += "</p>" 

This would be sililar to what VSCode uses on the right side for the items.

But it would be useful to know if other language servers use the fields in the same way.

[ryuukk]

Any news on this?

This is annoying because the current popup is unreadable, most of the info is hidden because too mutch duplicate informations

it is lot of noise

[rchl]

From the servers I'm using regularly (LSP-typescript, LSP-pyright, LSP-vue, LSP-dockerfile, LSP-json, LSP-terraform, LSP-yaml), none of them supports labelDetails it seems (or at least not for the completions I've tried) so the impact of such change would probably be pretty low but ideally someone who uses server that supports it should make such change and run with it for a while to see the upside and downside clearly.

[ryuukk]

The more we have to wait, the more i'm suggesting people to use vscode instead

zigtools/zls#507

I just sent this PR over there, and it works out of the box with vscode

It is a shame that it takes that long for sublime text to eventually think about an eventuality that it could eventually be added in the future, eventually

[rwols]

What do you mean by “sublime text”? We’re all unpaid volunteers here. Please also research clangd on how it renders the labelDetails.

[ryuukk]

What clangd does is incomplete

You need to understand why the feature was created and proposed for the LSP 3.17 spec

microsoft/vscode#39441

It is to show information on all the completion items, not just the selected one, otherwise it makes no sense

I understand it is volunteers effort, i volunteer my time to improve many people's experiences too, i am just sad nobody follows, sublime is not open source, so there is nothing much i can do other than bump issues i opened

[rchl]

LSP is open source and it's possible to experiment with it per @jwortmann's comment. But if you'd expect a more complete solution from Sublime Text itself then it would need to be requested in its bug tracker (if it isn't already).

[rchl]

The typescript server now implements support for labelDetails (behind a flag) and it looks far from ideal in ST:

It provides two completions, one bar and one bar(x) {} snippet but label is the same for both.

[rchl]

I guess best ST can do is something like below which looks rather weird.:

...or...

[rchl]

Or we could in fact try to put this into the trigger. The claim that it would make filtering worse would have to be tested.

[rchl]

Did a quick change for testing: #2002

[ryuukk]

Did a quick change for testing: #2002

Thanks!

As expected, the result looks a little bit hard to differentiate, wich ends up being the hack that was used prior to that LSP suggestion

Something like that would be better

Can theming be applied to that string so a contrast/brightness filter could be applied?

[rchl]

No, the left-aligned part of the completion is a plain text and can't have styling applied.

[rwols]

As expected, the result looks a little bit hard to differentiate, wich ends up being the hack that was used prior to that LSP suggestion

This influences the matching algorithm, which is not acceptable for me.

Something like that would be better

Can theming be applied to that string so a contrast/brightness filter could be applied?

The effect you want to achieve cannot be done as there are only three slots in the completion widget which can be filled in; one is left-aligned and determines the matching, one is right-aligned and dimmed, and the last is a "detail" field (which can have styling).

If you want to have this "trigger detail" in ST, you need to open a feature request here: https://github.com/sublimehq/sublime_text/issues

[predragnikolic]

This was addressed with #2010

NOTE: there is still something that needs to be addressed on the server side

[rwols]

Summarizing, detailed label support is something that must also be supported from ST core. We can only do so much with the slots currently given. I hope the changes suite your workflow better. Overall I hope you get work done with your 3D engine regardless of the particular completion widget details.