I don't if other mail list members can view it in the mail box (while I can not, just find the when I browsing on the mail list archive):
Happy to know the Update of the OctaveX plugin.
I refactored the Octave plugin during 2020/05/10~2020/07/19. The code base for Octave is not well organized from a software engineer point of view. As a result, I decided to rewrite it and keep the protocol routines almost the same as routines in the python plugin. Your work on plotting helps me a lot, thanks!
I have some ideas/guidelines/best practices on how to write or maintain a plugin. Like:
1. The ability to override the built one using TEXMACS_HOME_PATH/plugins/
2. A protocol layer for plugin objects and TeXmacs documents
3. Keep external dependencies as fewer as possible
4. .......
In real life, I am not an Octave user. I did not code in the Octave language before. I hope that you can create PRs to
https://github.com/texmacs/octave. Thanks for your awesome work.
Sometimes, as a open source project contributor, creating a PR but not get merged, may be disappointing. For TeXmacs plugins, I think most of them should be driven by the community. I planned to develop a command line plugin manager:
1. We maintain a catalog of community plugins under a git repo (like homebrew)
2. Using the plugin manager command line, we can install and uninstall a plugin at a specific version easily
3. Specs for a community plugin (like a metadata json under the root dir of the project)
In this way, plugin authors will not spend too much extra time talking with TeXmacs developers. However, we encourage people to contribute to the built-in plugins or even claim to be maintainer of it.
But have not started to develop on it yet.