Completions overhaul

[jwortmann]

Alternative to and discussed in #2002.

[ryuukk]

It's missing something, it doesn't strip the label at the end

For comparison, VSCode:

{
	'items': [{
		'kind': 14,
		'sortText': '2_5_alignof',
		'data': None,
		'label': 'alignof',
		'labelDetails': {
			'description': 'Keyword'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_StateID curr_state',
		'detail': 'StateID curr_state',
		'data': None,
		'label': 'curr_state',
		'labelDetails': {
			'description': 'StateID'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_Engine engine',
		'detail': 'Engine engine',
		'data': None,
		'label': 'engine',
		'labelDetails': {
			'description': 'Engine'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_Framebuffer fb',
		'detail': 'Framebuffer fb',
		'data': None,
		'label': 'fb',
		'labelDetails': {
			'description': 'Framebuffer'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_bool in_transition',
		'detail': 'bool in_transition',
		'data': None,
		'label': 'in_transition',
		'labelDetails': {
			'description': 'bool'
		}
	}, {
		'kind': 14,
		'sortText': '2_5_init',
		'data': None,
		'label': 'init',
		'labelDetails': {
			'description': 'Keyword'
		}
	}, {
		'kind': 14,
		'sortText': '2_5_mangleof',
		'data': None,
		'label': 'mangleof',
		'labelDetails': {
			'description': 'Keyword'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_UIRenderer mui_renderer',
		'detail': 'UIRenderer mui_renderer',
		'data': None,
		'label': 'mui_renderer',
		'labelDetails': {
			'description': 'UIRenderer'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_StateID next_state',
		'detail': 'StateID next_state',
		'data': None,
		'label': 'next_state',
		'labelDetails': {
			'description': 'StateID'
		}
	}, {
		'kind': 14,
		'sortText': '2_5_sizeof',
		'data': None,
		'label': 'sizeof',
		'labelDetails': {
			'description': 'Keyword'
		}
	}, {
		'kind': 14,
		'sortText': '2_5_stringof',
		'data': None,
		'label': 'stringof',
		'labelDetails': {
			'description': 'Keyword'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_float transition_current',
		'detail': 'float transition_current',
		'data': None,
		'label': 'transition_current',
		'labelDetails': {
			'description': 'float'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_bool transition_finished',
		'detail': 'bool transition_finished',
		'data': None,
		'label': 'transition_finished',
		'labelDetails': {
			'description': 'bool'
		}
	}, {
		'kind': 6,
		'sortText': '2_2_float transition_time',
		'detail': 'float transition_time',
		'data': None,
		'label': 'transition_time',
		'labelDetails': {
			'description': 'float'
		}
	}, {
		'kind': 14,
		'sortText': '2_5_tupleof',
		'data': None,
		'label': 'tupleof',
		'labelDetails': {
			'description': 'Keyword'
		}
	}],
	'isIncomplete': False
}

[rchl]

Uses this logic in that case:

LSP/plugin/core/views.py

Lines 963 to 969 in ac91446

	elif lsp_label.startswith(lsp_filter_text):
	trigger = lsp_label
	annotation = lsp_detail
	if lsp_label_detail:
	details.append(html.escape(lsp_label + lsp_label_detail))
	if lsp_label_description:
	details.append(html.escape(lsp_label_description))

Could possibly show labelDetails.description in annotation but then the detail would have to be in the bottom field or just not shown.

[jwortmann]

Maybe it would be more consistent to use annotation = lsp_label_description or lsp_detail in all of the cases, meaning that labelDetails.description will always be used as a replacement for detail. But it seems to me that this server doesn't really follow the descriptions from the LSP specs on how to use the different fields.

CompletionItem.detail should be used for e.g. types:

        /**
	 * A human-readable string with additional information
	 * about this item, like type or symbol information.
	 */
	detail?: string;

CompletionItem.labelDetails.description should be used for e.g. file paths:

	/**
	 * An optional string which is rendered less prominently after
	 * {@link CompletionItemLabelDetails.detail}. Should be used for fully qualified
	 * names or file path.
	 */
	description?: string;

I would argue that file path or fully qualified name is less important than type information, and therefore should go into ST "details" pane at the bottom (currently used logic).

But feel free to open a PR with an improvement. However, if we change the "annotation" as suggested above, and another server uses the fields according to the descriptions in the docs, then we have a problem.

Also it says that labelDetails.description should be rendered after labelDetails.detail. But in the given payload, the server doesn't provide labelDetails.detail for the items - so it's unclear what to do with labelDetails.description then or if we should just ignore it in this case.

[ryuukk]

That make sense, i will try to send a PR to fix that behavior for this particular server

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