Future development

[davidgranstrom]

Rationale

scnvim was initially written in a time before the lua interpreter was a part of nvim, it actually started out as remote plugin using the python3 provider. When nvim-v0.4 was released with an embedded lua interpreter I ported the code from python3 to lua, and as a consequence the plugin became a lot easier to install and maintain since there were less moving parts. Since the lua integration and the API has seen a lot of recent activity and improvements in the Neovim development, I would like to continue refactoring the plugin to remove as much viml as possible. The reason is in part that I personally enjoy working with lua rather than viml, but I also hope that the barrier of contributing would lower since lua has a larger user base and is perhaps generally thought of as an easier language to learn. A testament to this is all of the really interesting and well written (lua) plugins that has seen the light of day since the release of nvim-v0.5.

Apart from refactoring, which is good from a developer perspective, but maybe not as interesting for users (apart from bugfixes and performance improvements etc.), I also think that there are some features still missing to make scnvim a better SuperCollider frontend. One of those things is to get more help from the plugin for displaying function signatures (be able to see the argument order in function calls). This is also very closely tied to better autocompletion support in general. At the moment this is ctags based, and while it already gives suggestions, more intelligent and contextual completion would be preferred especially for method calls. Another point is syntax highlighting which has already seen an improvement with Mads Kjeldgaards work on tree-sitter-supercollider. Work has been started to mitigate the issue of signature help and autocompletion in this PR. I'm still not convinced however if this is the way to go, IMHO the real solution would be to implement a sclang LSP server, however this is no small task in itself.

The above point brings us to another point which is general communication between nvim and SuperCollider. At the moment this is done via raw UDP packets of json formatted strings. This is not a very idiomatic way of communication in SuperCollider since it already has a very strong OSC implementation. I would therefore like to switch communication protocol to OSC exclusively using osc.nvim. This plugin would be bundled into scnvim itself as to not require an additional dependency, and will hopefully also open up more ways of controlling the editor and further improve the intercommunication between nvim and sclang.

These are just my personal thoughts about what the future development of scnvim would be, but I'm very interesting in feedback on this and also to hear more ideas and suggestions for features and use cases which maybe I'm not familiar with or have thought about.

Roadmap

1. Start to port viml to lua. This would preferably be done module by module
   in an iterative fashion starting with modules in autoload/.

2. Use OSC communication between the editor and sclang

   1. Code evaluation and REPL feedback would still be done through stdin/stdout as it is now.

3. Improve function signature (argument hints) help and autocompletion.

   1. Could be a continuation of #145 or a standalone sclang LSP server.

4. Integrate stronger support for
   tree-sitter-supercollider and the possibilities
   that tree-sitter opens up for.

Apart from the above roadmap there is still of course room for contributions of any kind. If not code contributions it could be small things like typos in the documentation or improvements and additions to the scnvim-wiki, every little bit helps to make scnvim a better, stable and more usable plugin.

[molleweide]

This gonna be super cool!!!

[madskjeldgaard]

Sounds really great! Let me know if

I can help out with any tree sitter stuff. If anyone's curious, this video gives a good overview of what's possible. I personally use this to smart rename which I guess is kinda in LSP territory. Let me know if I can help with anything in TS integration (otherwise I highly recommend the playground plugin to mess around with the TS node tree even though it for some bizarre reason seems broken for sc at the moment.

[madskjeldgaard]

i agree that LSP would be the real solution to some of the code signature ish stuff but within the scope of a document, tree-sitter can do this as it is now I think. Not sure how to do it across documents, but I think that would be the task of an LSP server more than TS anyway.

[salkin-mada]

Good news @davidgranstrom <3

[davidgranstrom]

Thanks for the comments everyone!

I've started work on the OSC communication layer on this branch. Still very WIP but I think its going reduce overall complexity of the code base in the end (no more marshalling of raw JSON strings between sclang and nvim). It will also open up for the possibility to register handlers and send OSC data from nvim through the scnvim API for further extensibility of the plugin.