Allow multiple hover results

[Richardk2n]

The language server already handles lists as contents, so this simple change allows for multiple results (e.g., from plugins) to be presented to the user.

This is interesting for use cases like python-lsp/pylsp-mypy#63

[Richardk2n]

Maybe this should be extended to also allow lists from plugins. What do you think of this PR in general @ccordoba12 ?

[krassowski]

Is there an advantage to allowing returning list over the hook returining a dict with list on contents (as is already possible)?

• 1. the proposed change seems to possibly add maintenance overhead (e.g. what if someone wants to return multiple contents but also adds range?)
• 2. The specs indeed allows a list of MarkedStrings but those are deprecated, so I am not convinced if we should add extra behaviour depending on it (unless we can update spec to allow for MarkupContent[] too)

For reference:

/**
 * The result of a hover request.
 */
export interface Hover {
	/**
	 * The hover's content
	 */
	contents: MarkedString | MarkedString[] | MarkupContent;

	/**
	 * An optional range is a range inside a text document
	 * that is used to visualize a hover, e.g. by changing the background color.
	 */
	range?: Range;
}

[Richardk2n]

Currently, (as I understand it) the server accepts one hover response

python-lsp-server/pylsp/hookspecs.py

Line 92 in 363d864

@hookspec(firstresult=True)

As one of the included plugins gives an empty response by default

python-lsp-server/pylsp/plugins/hover.py

Line 27 in 363d864

return {'contents': ''}

it is not possible for 3rd party plugins to use the hover functionality.

I would like to change that.

It is possible for one plugin to return a list of contents. What my PR does (with significant room for improvement) is merging the output of multiple plugins into one such list of contents.

I was not aware of the details of the spec (did not know about the range). Can you please point me to the relevant document?
ii) If you can do that easily, that would possibly be a sensible change, but I fear your point i) still stands. Associating one range with multiple results is questionable. They would often be identical and one could argue that it makes sense to merge them, but neither is a particularly correct solution. Logically multiple such results would need to be emitted by a single request, which is probably not feasible.

So to conclude, I still would like to see this functionality extended to allow results from multiple plugins (at the same time), but I do not know how to do this properly. If you can point me in the direction of a solution, I would gladly implement it. Otherwise, feel free to close this.