[Idea]: IDE integration via autocomplete

[KevinStirling]

What problem does this solve?

There are certain times I wish I could access my codecaddy snippets inside of my editor, just so that I dont have to inturrupt my flow by opening a browser, navigating to codecaddy, searching for the snippet I need to copy, then switching back. I think being able to access your private snippet collection from and IDE / machine could be really powerful, especially if my auto complete just knew exactly what snippet I am looking for based on what I am typing!

Your proposed solution

I think this could be done by integrating with editor snippet engines / autocompete, and we will possibly need a basic plugin depending on the editor just to generate the snippet collection file. To see how we could generate snippet files as a baseline, I was messing around with this snippet generator tool that generates for some common IDEs.

To implement this, you need a prefix defined, which is what the autocomplete searches against as you are typing in the editor, and the body, which is the snippet contents. I'm thinking we can set the codecaddy snippet name to the prefix just to start playing around, and see if that is enough.

I started digging into how this might be possible with neovim, specifically with the autocomplete plugin I have been using, blink.cmp. Blink accepts snippets from many different sources, mostly other snippet engine plugins. However, they also support "custom snippets", which simply looks for VSCode style snippet files in ~/.config/nvim/snippets. see here. Looking into it further, it looks like Zed uses this format as well, so that knocks out 3 editor file formats right there!

With this specific neovim auto complete plugin though, all you need to do is add a json file in the default snippets dir, titled {target-language}.json (in my case I used lua.json. You can also use all.json, in which case the snippets will appear for every language.

~/.config/nvim/snippets/lua.json

{
  "caddy hi": {
    "prefix": "cc hi",
    "body": [
      "hello caddy"
    ],
    "description": "caddy hi"
  }
}

Result in editor

Since caddy has language detection already, we could use this to generate the language specific snippet files. Only hesitation with this is, if the auto-detect in caddy is missing a certain language, it will choose what it thinks is the closest. In this scenario it would probably be best to just fall back to adding the snippets to all.json, but I don't know if that fail state is possible on with the auto-detect library.

In neovim's case, I think this could be done pretty simply with a basic plugin to auth with codycaddy, pull snippet collections, and generate the colletion json files.

Looking forward to hearing your thoughts!

Alternatives considered

No response

How important is this to you?

Nice to have

[ddymko]

Hey @KevinStirling,
Thanks for the suggestion and the detailed write-up! We've been thinking about adding IDE support (VS Code and JetBrains), but the autocomplete angle hadn't crossed our minds. I think this is pretty interesting. We have a formal structure to follow, which means we can integrate with existing IDEs and further integrate CodeCaddy into developers' tooling (which is awesome).

I'm thinking we can set the codecaddy snippet name to the prefix just to start playing around, and see if that is enough.

That should work fine to start. We could also look at setting a specific tag with a prefix like prefix-{whatever} and parsing out {whatever} as the prefix. That might give us more flexibility without overloading the snippet name field. Thoughts?

One question on how these plugins fetch data: CodeCaddy supports both local and cloud snippets. Do we have flexibility in how and where we pull each source from?

For local, we have plans to expand the local ecosystem with a central store on the machine. That would let all CodeCaddy extensions, apps, etc. fetch local snippets from a single place. For cloud, we'd need to expose our APIs for you to integrate against. This also aligns with the CodeCaddy CLI, which can handle authentication, setting up the local environment, and establishing creds for the backend API.

As for language detection, we have a list of "major" languages, but if we're missing any, we can definitely add them and improve detection.

Let me know what you think on the prefix approach and the local/cloud fetching question, and I'm happy to dig into any of this further.

[KevinStirling]

That should work fine to start. We could also look at setting a specific tag with a prefix like prefix-{whatever} and parsing out {whatever} as the prefix. That might give us more flexibility without overloading the snippet name field. Thoughts?

This sounds good, could fall back to title if no prefix tag is given.

One question on how these plugins fetch data: CodeCaddy supports both local and cloud snippets. Do we have flexibility in how and where we pull each source from?

The specific autocomplete plugin that I mentioned leverages existing popular systems such as VSCode's style json snippets only (I believe the other popular autocomplete plugins follow this pattern as well). It seems very basic in that it just loads the json file into memory on start up.

I could see this could be an issue if you want it to refresh with new data from the caddy server while the editor is running, but I think to start we can just have the codecaddy plugin updating that json file on startup. Source should not matter as long as the plugin can make http requests.