Deprecate Cursorless snippet format in favour of community snippets

[pokey]

• Migrate "snip make" Cursorless action to output to community snippets dir #2354
• Create "migrate snippets" command that will automatically migrate all of a user's snippets #2355
• Update documentation instructing the users to use community snippets #2733
• Generate snippets for community format #2744
• Added voice command to migrate Cursorless snippet to community format #2747
• Migrate snippets follow up #2789
• Update snippets to use multiple language variants talonhub/community#1718
• Migrate snippets support to community snippets, support multiple snippets #2804

Later:

• Remove deprecated Cursorless snippets #2858

Re-add functionality that was only supported by legacy snippets:

• [/] Context specific scope matching (i.e. method inside of a class versus outside)
  @pokey will try to use "snip method". Adding a bunch of machinery for a single snippet in a single language was deemed (probably) not worth it.

Tabled:

• Move snippet autoformatter into cursorless monorepo #2356
• Add type hints to snippet formatter extension #2357

[jaresty]

What do you think about having the migrate command optionally migrate to the directory specified as the user's snippets directory? (In case folks want to keep snippets outside of community). Asking for others like me, since I don't need to migrate 😀

[pokey]

If you have a custom snippets directory, then yes that's where they'll end up

[jaresty]

Awesome, thank you.

[pokey]

@AndreasArvidsson reading this one again, I think this change would make the entire Snippets component that you moved to VSCodeSnippets in #2478 will just go away entirely, because Cursorless VSCode would no longer be responsible for keeping track of snippets at all, as we'd always send the body from community. Does that sound right?

So the only place we'd be using the file system would be for "snip make", but we can figure out a way to make that work. The key thing is that we will no longer need a Snippets component so we really don't care about moving it into file-system-common / upgrading it to new format / changing it to use file watcher. Did I get that right?

I guess there's the issue of Cursorless keyboard, but we could probably make that work external to the engine, the way the rest of cursorless keyboard-specific stuff is done in vscode side today

[AndreasArvidsson]

Unless we want to support named snippets for Cursorless keyboard, then yes.

That sounds correct.

[pokey]

Yeah I think if we wanted to support named snippets with keyboard we'd do it external to engine, like the rest of keyboard support

[AndreasArvidsson]

Then there is no problem :)

[phillco]

After discussing this with @AndreasArvidsson, we've updated the list of planned items in the description.

At this time we are not planning to make a dedicated third extension for VS Code functionality for snippets specifically, because we don't have the time/CI expertise/etc, so Andreas is going to put those two pieces (type hinting and autoformatting) into his extension, since they are nice to haves and not requirements.

Down the line, we do see a place for a "Talon [Contrib] VS Code" extension that would do these things alongside things like automatically formatting the treesitter scope format, which isn't somebody's personal extension, once usage of these features merits it. I think one thing that we do agree on is that these small individual pieces don't merit individual extensions, this raises the overhead of maintenance to be too high. But a common "contrib" extension makes sense.