-
Notifications
You must be signed in to change notification settings - Fork 163
Upstreaming LSP protocol extensions? #431
Comments
(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.) |
@bizzyman mentioned a few discussion threads (all seemed stalled) in emacs-lsp/lsp-ui#73
We could propose to make 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 |
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. |
We also need document for these extensions, and unify it with https://github.com/cquery-project/cquery/wiki/FAQ https://github.com/bizzyman/LSP-Symbol-Outline/blob/master/lsp-symbol-outline.el looks promising to me! |
Please chime in on this new proposal : microsoft/vscode-languageserver-node#367 |
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?The text was updated successfully, but these errors were encountered: