Extendibility of unified-language-server

[M3kH]

First of all thanks for the great libraries 🎩

I'm currently playing with unified-language-server.
While using it I notice that I needed some changes, but maybe those can be beneficial to others.

I'm not sure reflect the direction but if needed I can create Issues and/or PRs.

So here are the list of changes that I got so far:

• I export unistLocationToLspRange

  @@ -82,7 +85,7 @@ function isValidUnistPoint(point) {
    * @param {UnistPosition|null|undefined} position
    * @returns {Range}
    */
  -function unistLocationToLspRange(position) {
  +export function unistLocationToLspRange(position) {
     if (position) {
       const end = isValidUnistPoint(position.end)
         ? unistPointToLspPosition(position.end)

  This is handy because I can use manually create Diagnostic from node.

• If the message contains a Diagnostic I return the diagnostic in vfileMessageToDiagnostic

  @@ -102,10 +105,14 @@ function unistLocationToLspRange(position) {
   /**
    * Convert a vfile message to a language server protocol diagnostic.
    *
  - * @param {VFileMessage} message
  + * @param {VFileMessage & { diagnostic?: Diagnostic }} message
    * @returns {Diagnostic}
    */
   function vfileMessageToDiagnostic(message) {
  +  if (message.diagnostic) {
  +    return message.diagnostic
  +  }
  +
     const diagnostic = Diagnostic.create(
       unistLocationToLspRange(message.position),
       String(message.stack || message.reason),

  This is useful because I can pass custom Diagnostic that I create my self with VFile.Message and Object.assign.

• Return the connection and documents from the constructor.

  @@ -156,6 +163,8 @@ function lspDocumentToVfile(document, cwd) {
    *
    * @param {Options} options
    *   Configuration for `unified-engine` and the language server.
  + *
  + * @returns {{ connection: import('vscode-languageserver').Connection, documents: TextDocuments<TextDocument> }} res
    */
   export function createUnifiedLanguageServer({
     ignoreName,

  @@ -502,4 +539,6 @@ export function createUnifiedLanguageServer({
   
     documents.listen(connection)
     connection.listen()
  +
  +  return {documents, connection}
   }

  This allows me to complete my implementation and implement extra features such as onCompletition or onCodeActionResolve

• I accept an argument onCodeAction a callback that if return an handler then doesn't continue with the parsing of the Diagnostic.

• I currently hard-code my requirements for capabilities in onInitialize, but I will believe that this can also be pass as an option.

Please feel free to cherry-pick or discard any of the above proposal,
but if you accept my contribution I will be happy to help.

[remcohaszing]

I export unistLocationToLspRange

We already have unist-util-lsp. The goal was to reuse that library in unified-language-server to replace unistLocationToLspRange and somewhere else. However, that other place no longer has a need for it.

The problem is that unist-util-lsp expects valid input, but vfile message positions may be invalid. There’s some discussion in vfile/vfile-message#15. However, invalid positions should still be handled. I would most welcome a PR that makes unist-util-lsp accepts the same input as unistLocationToLspRange and another that updates unified-language-server to use that.

[M3kH]

This is interesting, in my specific case I'm creating the message in the parsing function, so I guess I could leverage the unist-util-lsp since my source is node from a unist.visit.

I can look into implement those changes.

[remcohaszing]

What is your use case exactly? If you have a rule that explicitly sets message.diagnostic, that means it’s bound to the language server, which doesn’t sound great.

I’m open to extending the interface to return connection and documents, but I would like to understand the use case better.

Are you using remark / rehype / retext / redot / MDX? Something else?

What should be considered public interface to support this? Could we even implement new API calls without a major version release if we expose this?

Should we even call connection.listen() if we expose more?

[M3kH]

I think my usage is a bit different than usual.

I'm Emacs and org-mode user (I usually don't start conversations like this :-) ).
I'm try to abstract some of the org-mode functionalities into lsp and extend markdown to support them.

This includes:

• Tangle/Detangle Codeblocks
• "Build" / pre-process
• Run Codeblocks
• LSP Proxy Codeblocks to other LSP

I build on top of remark / rehype and I will like to retrofit into reorg.
The changes I proposed are mainly to solve the last two.

I must admit, looking at my situation, LSP plays a central role, which is not the case for unist and family.
In fact proxy the errors back with file.message feels like a patchwork and I might need to switch to a custom lsp implementation anyway.

But I still share the foundations which is build with unist/unified and I will love to use the entire ecosystem that you make available, to build a linter, plugins, etc...

So I thought I could give back something :-)

Hope this helps.

[remcohaszing]

I'm Emacs and org-mode user (I usually don't start conversations like this :-) ).

Oh no! I use VSCode/Vim. And so the editor war begins…

---

Jokes aside, it’s awesome to see another ecosystem based on unified!

unified-language-server is basically an LSP version of unified-args. I recommend to have a look at remark-cli / remark-language-server / remark for VSCode. You may want to implement those for reorg for linting purposes, but I think it’s best to implement a separate language server for the other purposes you describe. I see how other unified-related utilities can help. :)

I also work on @mdx-js/language-server. MDX is also part of the unified collective. We have an open issue for handling code blocks (mdx-js/mdx-analyzer#287). I concluded that proxying LSP requests to another language server isn’t part of the spec. Did I miss something?