goldenstein64/lua-lsp-lib

A library aimed at making the construction of language servers in Lua easier.

lua-lsp-lib's Issues

Batch requests are not handled properly

According to the JSON-RPC spec here, batch requests are done by sending an array of request objects. The server should respond with a corresponding array of response objects. While the lsp.io module can handle arrays of requests, it's currently unable to send an array of responses back; it just sends each response in a separate message, which is presumably wrong.

`transform.position` tests expect `character` to refer to a codepoint position

transform.position tests expect character to refer to a code point, which means that a test like this is written wrong.

emoji_text = "🤗🤗\n🙂😀\n\n🤣😅\r\n😊\r💥"

-- testing for '🤗', the second code point
assert.equal 5, from_lsp emoji_text, { line: 0, character: 1 }

In that case when under a UTF-8 position encoding, character should be set to 4, and under a UTF-16 position encoding, character would be set to 2. This would be correct for UTF-32 though...

`transform.position` doesn't handle UTF-16 character offsets

Right now, it only handles UTF-8, which means the client would currently need to offer support for UTF-8 in its positionEncodings capabilities. LSP requires that the language server must offer a UTF-16 position encoding as a fallback.

The current plan for fixing this is:

1. Make transform.position more agnostic by first turning the document text (preferably the line in question) into a list of codepoints (like JS)

   • This might need to be cacheable to reduce the number of times each line in the document is transformed, but that would also mean that transform.position must be aware of a unique document identifier.

2. Make transform.position somehow aware of the choice in encoding, using one of two ways:
   a. Add an extra encoding argument, which forces position encoding/state management on the user (not the best UX)
   b. Add a set_encoding function or encoding property to transform.position

Additionally, the encoding could be set automatically by listen.handlers.initialize if (b) is implemented, although this would probably mean redirecting the processing to another module since capabilities need to be accessed in a safe way.

`transform.position`'s `encoder` field is not automatically set

Concerning a P.S. of #1

Additionally, the encoding could be set automatically by listen.handlers.initialize [...], although this would probably mean redirecting the processing to another module since capabilities need to be accessed in a safe way.