Language server protocol

Do you consider turning feedforward into an LSP? This way people can make plugins for whatever editor they prefer (including vim, emacs, kak, etc), and benefit from the pattern-tracking logic which is pretty much done

2 Likes

Hi @ghales, I split this into a separate topic. I hadn't heard of LSP until now, looks super interesting:
https://langserver.org/

@lwlsn and I have been looking at getting better comms between tidal and atom with OSC, this looks like it could be a more general solution.. I wonder if it bakes in particular ways of working? If it's flexible enough to support that pattern tracking, that could be nice. Are you familiar with it?

1 Like

Hi! I have no experience at all coding LSPs, but I've used them in the past, and they work pretty well (though new and kind of experimental).
It works via JSON communication between editor and server: the editor sends text data and the server sends display information - it's great for stuff like linting, auto-completion, maybe intellisense. Maybe the server can schedule these messages, or something, to update the highlight according to patterns.
Notice that the editor is responsible for display, including theming - this means the pretty highlight blocks would only work if the user's theme includes them.

This is what I gather, might be wrong

ps. People don't have to make plugins (!) : there are already LSPs for all major editors, it seems

1 Like

One of my favourite features enabled by LSP in other languages is error checking as you type. I would certainly welcome checking for potential errors in a pattern before I evaluate it :slight_smile:

I'm not an expert (only an end-user leveraging LSP capabilities at my day job), but it seems that it should be possible to define custom extensions for the Tidal LSP server in case standard LSP protocol would not be sufficient. Such custom extensions would require some code on the client-side as well, which means writing some IDE plugin to be able to handle them. In case of sticking to the standard LSP messages, a lot of editors would support it out-of-the-box (as @ghales mentioned above).

Note: there seems to be some LSP server for Haskell, so perhaps we could leverage it for some use-cases: https://github.com/alanz/haskell-lsp

1 Like

checking for potential errors in a pattern

Well. This requires a re-implementation (for the mini language) of several components of a (Haskell) compiler (parsing, name resolution, type checking). But some parts of this are already there?

For checking actual Haskell code (e.g., when working on Tidal source) I think the currently recommended package is https://github.com/haskell/haskell-language-server . I have seen it work (in emacs and atom) for navigation (jump-to-definition, jump-to-error-location). That's already quite useful. Apparently it does not do refactoring (e.g., renaming) but that's next on the agenda.

1 Like

That's a great starting point!