Providing a language server implementation for coconut

[nicksspirit]

Thanks to Microsoft's language server protocol there are tons of opensource implementation of LSP in other languages (there are even two implementations for python).

I would like to start a discussion on how it would look like for Coconut. Also what about static code analysis like flake8 or pylint, what would that look like?

[rtbs-dev]

Since a lot of folks use lsp in emacs (e.g. doom emacs), this could "solve" #454 for the time being, until someone works on expanding a major mode for it specifically.

[rtbs-dev]

We may want to merge this with #537 and #539 , possibly #454.

Also unsure if maybe a few of us could get together and figure out the best way to help here. I've done a bit of searching around how one might go about adapting the current sublime syntax setup over to an LSP config, but still unclear as to the best path forward.

[FelipeSharkao]

I don't know much about LSP, but maybe it could be done warping a Python Language Server of the compiled code and source mapping it back to coconut code.

[chrischen]

Hi guys just found you guys on Hacker News and I just happened to want to do piping and currying in python recently. Currently I just have my python LSP pretend coconut files are python, and it's working for syntax highlighting in neovim but really missing the LSP which is the main obstacle from further adoption for me.

[rtbs-dev]

@evhub based on preliminary investigation, I think this is possible with something like pygls, perhaps even able to write the lang server in coconut, since it's a python superset.

EDIT: We could probably learn from the folks over at HyLang, since they did very similar for their lispy-python. This LSP implementation by @rinx requires using

• pygls to actually template out the lang server to be compatible with all the LSP users out there (e.g. lsp-mode in emacs, or just straight-up vscode); along with
• some pre-defined API for auto-completion, annotations, and documentation lookup; in this case, that would be jedhy by @ekaschalk . Not sure if there's some api template/boilerplate helper we could exploit to reduce overhead?

Would you want this to be it's own repository? Would be easier to track issues/milestones and get help specific to this?

(tbh, would you consider a "coconut" organization on GH to keep the coconut packages together? I realize this is a separate issue, perhaps :sweat_smile: ...)

[evhub]

@tbsexton Seems like a good plan, and probably best to have it in its own repository. I'd also be happy to maintain a Coconut language server once it exists—especially if it's written in Coconut. I may also just end up writing it myself, but I haven't done so yet.

Also probably not going to make a Coconut GitHub organization; doesn't seem worth the effort.

[evhub]

One place to start on this could be to wrap this Python language server implementation by adding a compilation step to incoming requests and modifying outgoing responses to convert from compiled code locations to source code locations (which can be done via inspecting line number comments).

[rtbs-dev]

Not to pivot things on this issue, but maybe a way (easier?) to get broader editor compatibility is to make a Tree-Sitter syntax?

This is possible less involved than a new LSP (the two can co-exist nicely), and tree-sitter parsers are a super nice way to get native syntax highlighting in e.g. Neovim, emacs, vscode, and even Helix Editor (which is what I'm starting to use for everything except... .coco files :sweat_smile:)

Since it's a separate-but-related issue from LSPs, I can open a new issue if you'd like? Here's some example parsers. Since there are bindings to a bunch of languages, people make the parsers in a bunch of languages.

• "official" python tree-sitter
• Newish/in-development grammar for Typst, a pretty nice rust-bast typesetting language

I realize this is probably a bit of a duplicated effort since you already run things via cPyParsing. Not sure if the dev effort is worth it on your end, but I know tree-sitter is already widely supported across a bunch of editors. And if I ever have the free time to learn it, I'd definitely be interested in writing a parser for Coconut to contribute back. :)