Support new VSCode extension type

[allaboutmikey]

As per this on the vscode-python github, it seems python tools extensions are going to change how they are packaged in vscode. Black, amongst others, has already been migrated to this new style.

It would be great if cercis was also available in this way, so I can keep using it instead of black when vscode deprecates the old way of setting the code formatter.

I am assuming of course that being based on black, there wouldn't be an enormous amount of work involved?

[jsh9]

Hi @allaboutmikey , sorry about the delayed reply! I have been busy with other things these past few weeks.

I think (and I may be wrong) that if Cercis keeps up with Black's updates (which I intend to do), Cercis will get Black's integration with VSCode out of the box.

Have you tried using Cercis with VScode before? (I have never done so before.)

[allaboutmikey]

No problem @jsh9. I have been using cercis with VScode, by changing the path to "the black executable" to point at cercis instead. This is the part that I understood to be changing, though I admit I'm not fully across the details of the implementation. The new way is to use the Language Server Protocol so the IDE talks to the addon via json based ipc. The advantage to cercis would be easy integration with a bunch of IDEs and tools that support this method. Hopefully, it is something that is either already done in the main code base, or doesn't require much effort to package.

[allaboutmikey]

This triggered me to do some more reading. All is not lost. It seems that black is packaged with the extension, and there is a setting for the formatter path:

black-formatter.path | Setting to provide custom black executable. This will slow down formatting, since we will have to run black executable every time or file save or open. Example 1: ["~/global_env/black"] Example 2: ["conda", "run", "-n", "lint_env", "python", "-m", "black"]

The warning suggests, though, that it might hurt performance accessing the formatter in this way. It might still be better to package up an extension with cercis embedded from the start. The code for the packaged back formatter extension is over here and appears on first view to be an LSP wrapper around black using a boilerplate looking approach. It seems like it might be a little bit of an effort to understand and modify this, but it looks like it would be a one-time effort at least.

When VScode updates force me down this path soon, I'll try the custom path option. Hopefully your time permits a look into the package approach at some point.