Great simple plugin that stays out of your way, but does exactly as required.
Oh, this is very neat, do you keep your fork of emmet-cli up to date with the upstream?
I do intend to keep it up to date with emmet-cli, I might keep it up to date with emmet-io if the maintainer of emmet-cli does not. I am not actively keeping track of changes with emmet-io but if I notice it breaking I will fix it.
I recall somebody in #kakoune mentioning that some language server was using snippet-syntax in ordinary completions, so it sounds like your plugin is already useful.
I see that snippets depend on Python 3 and a YAML plugin, which probably isn’t too difficult to setup in general, but might be a bit heavyweight for some tastes. Have you considered just having a snippets directory, where the filename is the snippet abbreviation and the file’s content is the snippet body?
I have not considered it yet. I think I prefer having all snippets in the same file instead of having multiple files.
Dependency on python is not a problem IMO, it is usually present on an arbitrary linux system. I can consider just manually parsing the file instead of using yaml.
Do you keep snippets for all languages in one file? Personally I’d prefer to split snippets per language.
I don’t have that much snippets yet, but splitting them per language seems reasonable. In addition, a different file could be loaded for a different language. Maybe the snippets should be stored in a kakoune option as in the first plugin of this thread. I will look into that.
I adapted the
snippet_files option to be str-list now instead of str. So it can hold a list of snippet files.
I also adapted the python program to read from multiple files now.
This option can also be adapted or overwritten per filetype using hooks.
I think storing the snippets in files is better than in a kakoune option afterall since this way means that the snippets refresh live when updated.
Nice, I think that is a huge improvement.
Yeah, however such snippets are just skeleton files that are being triggered on certain keywords. Real snippets managers feature real-time mirroring, nested placeholders, placeholders with scriptable behavior, visual placeholders, that can yank text and put it somewhere inside next snippet, placeholders with choices, where you’re prompted with the list of possible values, and are free to select one or replace it with your own.
As example of scriptable behavior, my snippet plugin for Vim has C++ class snippet, that can detect current file’s name, and create include guard with this name uppercase, and class named against filename, but in lowercase:
Or for example in UltiSnips vim plugin there are markdown snippets, that have variable length, and can adopt to the length of previous line.
Because today language servers are ready to use in most editors, I think that good snippet manager should be compatible with LSP snippets: https://github.com/Microsoft/language-server-protocol/blob/master/snippetSyntax.md
I kinda miss those features and planning to start working on implementation of UltiSnips like plugin for kakoune when I finish with plugin manager, and fzf. However I’m not sure that I’ll be able to do such complicated plugin in shell script.
I wouldn’t even try to do this in shell. Shell is fine as glue, or for simple scripts but it fails miserably for complicated programs.
If only you saw what I’ve saw in viml…
I’ve saw this plugin and thought that such technic can be used to create snippets for kakoune with placeholders, transformations, and other features of modern snippet managers like UltiSnips (vim) or yasnippet (emacs).
Simply by parsing a snippet and then putting a parsed text to file, one could store placeholder information as phantom selections like in that plugin and jump would just select next selection.