I've been working on a cross editor snippet manager and I was hoping to get some feedback both on the both on the design of the project and how I might go about making this something other people can easily jump into and contribute to.
It's getting less feasible for me to take this project on by myself(I sort of got to a point to where I feel like I code myself into a corner, and kind of burned out on it for the last few weeks). I actually have a lot of the ideas for this project fleshed out, and more or less know what's necessary to get from A->B, it's just not documented.
I plan on supporting scriptable snippets, but want to avoid just supporting arbiturary code execution, so I was thinking of just using some kind of wasm-based plugin systems where I could sandbox what scripts have access to(and just specify them like you would a variable in the snippet syntax like @dynamic_box(input))
I'm hoping to essentially have one client running for every open editor, and have thought about extending support for things like browser based editors. It's super difficult to handle in a cross platform way, but would greatly reduce the memory footprint for someone like me who can have 10 open terminal based editors.
the ultimate goal of this project is to make it where it's easy to write and share snippets that work across multiple editors, simplify the process of adding snippet support to new editors, and also make it to where snippets are more closely tied to libraries. basically reducing the amount of effort for the individual coder of churning out boiler plate code or common programming patterns (such as design patterns or families of algorithms) by increasing the incentive for group effort.
well that's quite an ambitious project you got there
Getting other people to contribute to your own project is never easy. I would start by rewriting your README:
What is Sniper and why should I care? What are its unique selling points? You do address this in your Why Use Sniper? section but after your todo list and Update on progress most people will have already lost interest. While your current Why section is well-written, so much text isn't really inviting. I'd present your main selling points with bullet points at the very top of the README (under a brief self-definition).
I think most people only contribute to projects they use. So after convincing the reader why they want Sniper you should give some simple instructions on how to get started (cargo install ..., install VS code extension, etc.). Try to make the setup as straightforward as possible.
Ideally your README has some eye-catcher maybe a GIF of your VS code plugin in action. And you should probably also demonstrate how you create snippets (can you do that through the plugin or do you have to run a command?).
With that said I think that competing against the established single-editor snippet managers will be tough. In particular because installing them is dead simple (a couple of clicks in your editor), whereas your cross-editor manager seems to require setting up a server. Also note that just "cross-editor" might not be the best selling point since most users only use a single editor, so you might want to focus on the cross-editor sharing aspect. You could even brand yourself as "the social snippet manager".
All in all I'd focus on building an enjoyable & convincing MVP. Good luck!
I don't mean to knock on anything but I've been having trouble imagining what that actually means in the 3 weeks since your post.
To my mind "snippet" implies some few lines of code that it might be useful to cut and paste from somewhere else into once project. Or at least shows how to achieve some goal.
Then I can imagine that if one does that a lot it might be useful to have some kind of manager, to store, index, categorise, search, share snippets.
But then I think... Any such snippet is never going to fit into any code I'm writing. It will need variable names changing, types changing, some how tweaking to fit what I'm doing. At which point it must be easier just to type the code into my editor as I want it rather than paste something that needs tweaking.
And... A significant piece of functionality in a snippet should probably be in a library/crate ready to use rather than duplicating and tweaking its text all over the place.
In short, snippets are what I find on forums like this, or stack overflow, etc. As examples of some idea about how to do something, not as actual code to cut and paste into my project.
unfortunately few snippet managers that I know of that make use of programmatic snippets, and because there is no standard syntax (the way that there is for dynamic snippets), each implementation is somewhat unique.
In my mind snippets have a few different use cases:
automating boiler plate syntax (if,else blocks with the ability to jump between placeholders)
automating design patterns, or well any part of coding where tedium or repetition kicks in. granted often this repetition is avoidable, by making a function or library, but often it's not.
the best example I can think of is leetcode problems: most of the problems in a given grouping have close to optimal solutions using the same algorithms or algorithm subpatterns. If you do enough of them and you've seen similar problems you'll start to recognize the solution pretty quickly, then it's basically you tailoring that pattern to the given problem. having the ability to type and activate a trigger, then fill in the rest with existing autocompletion and abusing the tab key will probably make it to where you could solve some problems in seconds.
While I think that is a pretty dumb use case, I do think that a lot coding problems can abstractly thought of as layers and layers of repetive patterns.
the (impossible) ideal is that the only parts of the code you write are the parts that are unique, with everything else being semi automated. Though that is impossible, I do think (dynamic/programmatic) snippets do help minimize the latency between thought and implementation
