package the package as a Macaulay2 package

[dimpase]

Presently this plugin is some sort of not too well-defined blob which can be installed in various ways, some of them hacky.
Should it become a Macaulay2 package?

Same applies to the other editor plugins: for emacs, for vim, etc.

(this option was mentioned in #14 (comment))

[joel-dodge]

I understood that this plugin was to be published to the vscode extension marketplace as in this guide: https://code.visualstudio.com/api/working-with-extensions/publishing-extension at least that is how i assume the recent release was published since I installed it from the vscode extensions menu. I guess installing via the VSIX format is the method that is hacky?

I am not sure if I understand how making this a Macaulay2 package would improve the situation though. Are there other packages like this that don't consist of m2 code but are bundled as "packages" somehow?

[johndcobb]

We previously had people install the package via a vsix file before we published the extension to the marketplace. Now, the way to install and keep up to date is to just search the extensions in vscode. More instructions here: https://github.com/Macaulay2/M2/wiki/Using-Macaulay2-with-VSCode.
Unless I'm misunderstanding, I would not expect a Macaulay2 package to interface with VSCode like we need

[d-torrance]

I think this idea makes a lot of sense for the editors whose code we distribute with M2 (Emacs and Vim). We basically do that already for Emacs (setupEmacs, which is in Core and not in a separate package), and I have a PR (Macaulay2/M2#4090) to make it more of a standard ELPA-style package.