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

the way sxpp's streaming lexer (tokenizer) works, UTF-16 and UTF-32 input streams are already supported.

since all controlling characters are well below 0x7f, and the lexer doesn't output strings, only token types and locations, you can just feed it 0xff clamped chars, and then offsets and positions are implicitly correct.

#devlog #sxpp #lsp

hm. Kate colorizes macros and comments, but not strings, numbers and keywords. idk what's wrong.

when i flip the token order, same result. when i make all tokens comments or macros, then they get colorized as such. it's weird.

#devlog #sxpp #lsp

got vscode to interface with my LSP but it sends no semantic token related RPC calls at all. no syntax higlighting.

terrible to debug - no error messages anywhere, everything fails silently.

#devlog #sxpp #lsp

i went on IRC and asked around on the kate channel, and we browsed a bit of source code together, and --

so it turns out Kate's LSP client simply doesn't highlight strings, numbers and operators.

i filed a ticket with the project, let's see how it goes.

https://bugs.kde.org/show_bug.cgi?id=519957

#devlog #sxpp #lsp

519957 – LSP Client Does Not Highlight Numbers, Strings, Operators

they closed the ticket, i reopened it.

#devlog #sxpp #lsp

the ticket got closed again. RIP Kate.

#devlog #sxpp #lsp

@lritter Disappointing.
@lritter I've been hoping for Lapce to become something useful but it's moving slow it seems. (No shade on those working on it.) VS Code is serving me fairly well but I still feel like I'd want something else. Preferably something more open.
@SonnyBonds what's ironic is i can't get semantic tokens to work in vscode at all. the client never sends the request. i see no mistake in my handling of capabilities. it works in kate.
@lritter Weird. I haven't actually done any LSP work but have it on my radar a bit because I might want to somewhere down the line.
@lritter "Sorry, not happening!" Quite the response if confronted with well laid out arguments...

@lritter
> nah I don't wanna

Crazy answer for a well laid-out feature request

@Igigog i would have written the patch myself if they wanted to.

i already had a contributor on irc who wanted to do it.

@lritter that’s uh… quite the response
@lritter their response is kind of why I still use Emacs in 2026: the lack of a vendor/user separation (since all extensions have access to practically all the facilities of core code) means you can just do this without having to consult the FSF