Sunsetting (but replacing!) the VSLilyPond suite

[lhl2617]

I started this project back about more than one year ago just as a fun little project to augment my LilyPond editing experience--I am a die-hard VSCode fan, and wanted to bring conveniences that Frescobaldi etc. brought to the table to VSCode.

I never realised that it'd actually be a tool used by actual people--there's a StackOverflow question about it, @kenakofer wrote a really nice guide for setting it up, and it has made its way into the lilypond-user mailing list.

Now, I do not intend to stop developing this! I in fact have more ideas on how to make VSLilyPond even better. Here's the catch however:

I developed VSLilyPond under my university Microsoft account, and due to a four-year-old issue that Microsoft doesn't even bother to ack, I will need to deprecate and replace this suite of extensions under a different publisher.

Deprecation will happen in June, and the replacement will likely be made over the summer in 2021, but as I'll be graduating (and joining Facebook), there'll be some complications, delays, etc.--no promises!

This is also a great chance for me to use better dev practices etc.--couple of
points for the plan will be

• Monorepo for VSCode extension
  Developing this suite of extensions under many repos isn't really nice IMO, there's some code duplication, especially in the deployment processes, that I'd love to get rid off. Having just one extension depending on nothing is much nicer, and bugs and issues can just be linked to one extension. I expect to continue relying on https://github.com/jeandeaual/vscode-lilypond-syntax however.
• Editor-agnostic LSP
  LSPs are "the thing" for language support in editors. It would be much better if an LSP server is written for LilyPond. It can still depend on the local LilyPond (+Python-ly) installation, but the best thing is that devs wanting to code LilyPond in another LSP-enabled editor (pretty much every good editor these days) could just use (and contribute to) the common LSP. This model has worked extremely well for gopls, which connects seamlessly to the official VSCode Go extension
• Better documentation
  LilyPond users may not necessarily be tech wizards capable of digging very technical docs out, so clearer and better documentation would help everyone. The biggest pain point is--as suggeested by the StackOverflow question above--setting it up. I'd commit to write clearer documentation, especially when errors occur. An example would be linking to a installation guide on the error inside VSCode if something wasn't set up wrongly.
• Better tests
  Tests currently do not run end-to-end on intellisense etc.--the atom version of the extension does: https://github.com/nwhetsell/linter-lilypond

Thanks for using and supporting VSLilyPond :)

[lhl2617]

Update--I have figured out how to get away with the account issue, and will not lose access to the publisher (and hence there is no hard requirement to replace this)--so I'll leave this for later! Will not try to fix it if it's not fundamentally broken for now.

[xhevahir]

Is LSP preferable to tree-sitter?

[lhl2617]

Is LSP preferable to tree-sitter?

@xhevahir Not sure if they're comparable? LSP is a suite of APIs for language analysis tools to talk to code editors, whereas tree-sitter seems like a cool project for parsing syntax trees.