alright. day 2 of LSP server coding.

i'm going to try and complete a handshake with Kate, the KDE source code IDE.

and the handshake works.

#devlog #sxpp #lsp

we have successful JSON parsing, object query, object construction and serialization.

now to provide an actual service. the most important thing is colorization, so that's first.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_semanticTokens

#devlog #sxpp #lsp

it's beginning to work!

numbers and strings are not being highlighted correctly yet, don't know why.

also, apparently tokens are not allowed to span multiple lines¹, so i need to fix up this part as well.

more tomorrow.


¹ multiline tokens can be supported by clients, but the server needs coverage for the fallback so why maintain two paths?

#devlog #sxpp #lsp

how does LSP encode text file positions: UTF-8? (what sxpp uses) UTF-32? (also sensible i guess)

neither. (well since 3.17 yes, but only if the client feels that way)

it's UTF-16. UTF-16 support is mandatory. why? because it's a damn microsoft protocol that's why¹. 😫

fortunately character offsets are line-relative so fixing that up is not too expensive.


¹ yes it's also because Javascript.

#devlog #sxpp #lsp

@lritter and this, kids, is a great example of a repeating pattern in all kinds of domains:

LSP the idea: great
LSP the reality: questionable

We can now continue our discussion of if mediocre realizations of good ideas are a net win or a net loss for the community. This has a lot of nuance and I expect 3 scrolls until next Tuesday, dismissed!

@artificialmind one could probably make a better protocol & provide a LSP adapter.
@lritter LSP in particular is "not that bad" in my books because the last time I wrote support for it, it was trivial to abstract away all the weirdness. I'm sure that is on accident because I've worked with plenty of "mid" stuff before that tried to infect your codebase as thorough as they can. LSP is surprisingly local in that sense.
@artificialmind you need a JSON and -RPC layer. that's a bit much already. transmitted documents are escaped and unescaped for no reason.
@lritter yeah from a dependency point of view you're right. But for the code organization it's not really viral. My compiler code produced typed LSP event output that I could unit-test normally. Then one submodule of my code did all the JSON+RPC+protocol weirdness and translated the typed events for the wire.
@artificialmind it's viral for JSON which is garbage
@artificialmind what kind of code organisations are viral?

@lritter I meant that sometimes it's not easy to build abstractions that keep the questionable design decisions at bay.

Like, if you try to abstract OpenGL (before direct state access) in a way that doesn't leak global state dependency, you only had bad choices basically. Slower perf, not playing ball with 3rd party code, etc..

That means OpenGL's "bad decisions" are your problem as well, in a viral way.

But LSP's "bad decisions" were confined to a corner in my code.

@artificialmind i see.

well it could always be worse: https://lv2plug.in/ (the linux VST analog from hell)

@lritter
> LV2 has a simple core interface

it can't be bad if it's simple right!! because simple == good!

@artificialmind they're not mentioning how your plugins need to be shipped with offline manifests written in https://en.wikipedia.org/wiki/Turtle_(syntax)
Turtle (syntax) - Wikipedia