Skip to content
This repository has been archived by the owner on Jul 30, 2020. It is now read-only.

Upstreaming LSP protocol extensions? #431

Open
HighCommander4 opened this issue Feb 7, 2018 · 5 comments
Open

Upstreaming LSP protocol extensions? #431

HighCommander4 opened this issue Feb 7, 2018 · 5 comments

Comments

@HighCommander4
Copy link
Contributor

HighCommander4 commented Feb 7, 2018

cquery implements a number of LSP protocol extensions (messages with names starting with $cquery/).

Is there interest in upstreaming some of these protocols to the LSP spec?

For example, for semantic highlighting, we have $cquery/publishSemanticHighlighting. There is an issue for semantic highlighting in the LSP spec issue tracker, with an associated pull request, which proposes a message similar to ours, with some differences (e.g. the ranges are not grouped by symbol kind). Discussion/review of it seems to be currently stalled. Should we contribute to that discussion, by e.g. showing what has worked for us and why?

@HighCommander4
Copy link
Contributor Author

HighCommander4 commented Feb 7, 2018

(The benefit of upstreaming, of course, is that the corresponding client-side support will eventually be in the editors themselves, and not our specific editor extensions.)

@MaskRay
Copy link
Contributor

MaskRay commented Feb 7, 2018

@bizzyman mentioned a few discussion threads (all seemed stalled) in emacs-lsp/lsp-ui#73

Further discussion of symbol hierarchy is here microsoft/language-server-protocol#327 , here microsoft/vscode#34968 and here microsoft/language-server-protocol#136

We could propose to make DocumentHighlightKind a bitmask enum (we'll have call,read,write,addressof after https://reviews.llvm.org/D42895

export namespace DocumentHighlightKind {
	/**
	 * A textual occurrence.
	 */
	export const Text = 1;

	/**
	 * Read-access of a symbol, like reading a variable.
	 */
	export const Read = 2;

	/**
	 * Write-access of a symbol, like writing to a variable.
	 */
	export const Write = 3;
}

Make textDocument/references responses Location[] include optional container information, and DocumentHighlightKind (this should probably be renamed, but SymbolKind is taken..)

@jacobdufault
Copy link
Owner

I'm happy if someone else wants to propose the extensions but from what I've seen lsp protocol is very slow to standardize new messages - basically because the spec is controlled by vscode it mostly caters to what vscode has native UI for.

@MaskRay
Copy link
Contributor

MaskRay commented Feb 7, 2018

@svenefftinge
Copy link

Please chime in on this new proposal : microsoft/vscode-languageserver-node#367

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

No branches or pull requests

4 participants