jokeyrhyme / nuls Goto Github PK

Language Server Protocol implementation for nushell

License: MIT License

Rust 100.00%

nuls's People

we should explore this first, as it might not be worth the trade-offs
how significant is the performance benefit?
how frequently would upstream code break backwards compatibility (i.e. what is the ongoing burden)

we should explore this first, as it might not be worth the trade-offs
this will make it easier to distribute the language server (as it will literally be in the same file that everyone is already downloading/compiling)
this would make the one nu executable larger/slower, but how much larger/slower?
can we assume that most people running nu are also writing code in the nushell language, and therefore most nu users will benefit?

Rust strings are UTF-8, and JavaScript strings are UTF-16
during initialisation, the client provides a list of compatible encodings, and the language server selects one and sends it back
we've currently hard-coded UTF-8, and https://github.com/nushell/vscode-nushell-lang likely depends on the LSP default which is UTF-16
we need to make sure that we support clients with either encoding, and that our text-traversing logic works in both cases

we've noticed that go-to-definition isn't always very accurate in terms of row/column
need to double-check the behaviour of the the VSCode extension in real VSCode

interested parties may follow new work elsewhere, per #8
the upstream PR is effectively glue-code between lsp-server and nu internals
this project (nuls) is effectively glue-code between tower-lsp and nu --ide-... processes
as such, most of the code in nuls fundamentally incompatible with the upstream work
as I'm running out of time to complete on this project, and the value of any further work is questionable (seeing how short-lived it would be), I'm archiving nuls in favour of the upstream PR (and follow-up PRs)

we're currently not feature-complete yet, compared to https://github.com/nushell/vscode-nushell-lang
but we should reach out and see if there's interest in moving/forking this project into the official organisation, and what other changes/responsibilities are in involved
ideally, we will have achieved the status of "not unmaintainable garbage" prior to doing this

currently, we do immediate a.k.a. leading-edge throttling/debouncing
this means the language server can hold a copy of a document that is up to 500ms out-of-date compared to user edits, causing various quirks/issues with diagnostics and positioning of inlay hints