cursorless
cursorless copied to clipboard
cursorless-dev
Deprecate Cursorless snippet format in favour of community snippets
- [ ] #2354
- [ ] #2355
- [ ] #2356
- [ ] #2357
- [ ] Think about "snip" / "snippet" spoken forms
- [ ] Pokey migrates to community snippets
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 😀
If you have a custom snippets directory, then yes that's where they'll end up
@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
Unless we want to support named snippets for Cursorless keyboard, then yes.
That sounds correct.
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
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.
I created a separate issue for removing the deprecated Cursorless snippets in the future https://github.com/cursorless-dev/cursorless/issues/2858
Everything in this issue that we need to do before 1.0 is now done! :D