A PML "Pseudo Lang Server" Only for Highlighting

[tajmone]

Highlight v4 introduced support for Language Servers:

• README_LSP_CLIENT.adoc — Highlight Language Server Protocol client

This is a powerful feature which allows highlighting syntaxes that might be too complex to implement with Highlight native language definitions. And I believe that it's also the first syntax highlighter to support LSP.

I've been tinkering for a while with the idea of creating a "pseudo Lang Server" for PML, for the sole purpose of highlighting documents via Highlight 4. This would mean that we wouldn't have to worry about error tolerance and performance, unlike with editors and IDEs, all we need to do is to highlight a PML source (which is assumed to be well formed). Also, there's no need to come up with smart caching solutions, etc., since in this case the Lang Server will only be used for a single pass.

Please see my Issue at Highlight repository

• https://gitlab.com/saalen/highlight/-/issues/185

And the original Issues that brought LSP support into Highlight, and the various challenges, etc:

• https://gitlab.com/saalen/highlight/-/issues/101
• https://gitlab.com/saalen/highlight/-/issues/177

NOTE — I've been an active collaborator of the Highlight project since a number years now. I really love Highlight and it's my favourite highlighter because it's simple to use, powerful and supports a huge number of syntaxes out of the box.

[pml-lang]

Highlight v4 introduced support for Language Servers

That's great.

creating a "pseudo Lang Server" for PML, for the sole purpose of highlighting documents via Highlight 4. This would mean that we wouldn't have to worry about error tolerance and performance

Clever idea. That would be a good PML/LSP start, to get the feet wet.

[tajmone]

Minimum LSP Features for an Highlight Pseudo Lang Server

Christian, we have some useful updates from highlight#185:

@tajmone: Since Highlight basically passes an immutable source file to the Lang Server, which are the minimum required LSP messages that need to be handled? What does Highlight expect?

André Simon: As a client, highlight first sends initialize with some capabilities, then initialized. After that, the input source is sent using textDocument/didOpen.
If highlight was invoked with the --lsp-hover option, textDocument/hover requests are sent for all keyword tokens.
If --ls-semantic was given, a textDocument/semanticTokens/full requeust is issued to get the semantic token list.
After all queries were sent a textDocument/didClose is sent and the next file will be processed.

So ... to implement a very simple proof of concept (i.e. without supporting the --lsp-hover and --ls-semantic options), a PML Pseudo Lang Server would only need to cater for the following LSP exchanges:

• initialize
• initialized
• textDocument/didOpen
• textDocument/didClose

and all their corresponding messages required on the Lang Server side.

This seems much more doable than a full-fledge Lang Server that needs to handle real-time updates to a source file being constantly edited (and the tons of specific protocol messages needed to handle them).

And if we also assume that only well-formed documents will be fed to the highlighter, we won't have to care about handling incomplete and broken constructs either — we'd only need to be tolerant for missing required attributes, which translated to simply treating all attributes as optional, to begin with.

I've always wanted to learn LSP Lang Server design, but am not up to the challenges of a full real-time tolerant parser; so this might be my entry gate to the LSP world, and my chance to achieve some small scale results too.

Lately, the centripetal dark forces of Real-Life daily needs have been forcibly dragging me away from the celestial Open Source world, punishing me for excessive procrastination of duties (mea culpa). But once I've managed to amend the situation, and cut out some extra free-time corners, I'd love to give it a go and start working on a PoC prototype of a dead-simple PML pseudo Lang Server for Highlight — maybe just scoping all nodes equally, and support all attributes according to their basic types, without validation.

Having a PoC prototype would already be a great starting point, regardless of the language its implemented in, or the number of PML features it supports. From there we could move on to something better. But right now the best compromise would be to come up with something that can be done quickly.