Creating code snippets is tedious. about vim-vsnip HOT 50 CLOSED

@hrsh7th

I have no plan to implement python interpolation, Vim script interpolation etc.

I'd like to try to make the switch from Ultisnips, but what's holding me is:

1. I find Ultisnips snippet format more readable
2. code interpolation

About 1., I think there could be a command like :VsnipImport that could be run from a .snippets ultisnips file, that would translate the snippets in json and add them in the vsnip json file, invoked like:

:VsnipImport        " parse and add to {filetype}.json if snippet is not existing
:VsnipImport!       " parse and add to {filetype}.json replacing snippets with the same key

About 2., it could be done with variables, example of vimscript interpolation:

{
  "demo": {
    "prefix": ["demo"],
    "body": [
      "demo $DATE",
    ],
    "description": "Demo for vimscript interpolation.",
    "DATE": "!vim strftime('%D')"
  }
}

from vim-vsnip.

I always use this command:
'<,'>s/"/\\"/ge | '<,'>s/\t/\\t/ge | '<,'>s/^/"/e | '<,'>s/$/",/e
Or

command! -range VsnipSnip silent <line1>,<line2>s/"/\\"/ge | silent <line1>,<line2>s/\t/\\t/ge | silent <line1>,<line2>s/^/"/e | silent <line1>,<line2>s/$/",/e

Which formats the given range of code into a proper json.

from vim-vsnip.

@jandamm I'm happy to include it but I think To escape should use json_encode instead of a manual substitute.
What do you think about it?

For example, echomsg json_encode('aiueo"kakikukeko\t') "=> "aiuoeo\"kakikukeko\\t".

from vim-vsnip.

You can install https://github.com/SvenBecker/vscode-pytorch/blob/master/snippets/pytorch.json via vim-plug or other vim's plugin manager.

BTW, I have the same opinion. currently, large snippet is tedious to convert snippet json.

My current thought is we should provide VsnipYankAsSnippetBody command when its provided, we can create snippet with :'<'>VsnipYankAsSnippetBody | VsnipOpen!.

from vim-vsnip.

Thanks, this is a great idea.

from vim-vsnip.

Why not give a try parsing the snippets from https://github.com/honza/vim-snippets?
For example https://github.com/honza/vim-snippets/blob/master/snippets/javascript/javascript.snippets should be parsable, and syntax is similar.

from vim-vsnip.

@hhaoao I think you should treat it as a template and not as a snippet.

from vim-vsnip.

Why not give a try parsing the snippets from https://github.com/honza/vim-snippets?
For example https://github.com/honza/vim-snippets/blob/master/snippets/javascript/javascript.snippets should be parsable, and syntax is similar.

From my personal point of view: vim-vsnip built-in fragment parsing of other plugins is not a good idea, it is very troublesome. This behavior should not be encouraged. The Microsoft Language Server Protocol is the gospel of vim. I think the current state of vim management code snippets is similar to js. We can follow the practice of improving js , introduce a template engine, and then the template engine will parse the template (such as "vim-snippets" fragments) to meet the requirements of the LSP protocol Format specification.
ps: Many excellent template languages for improving js, e.g. EJS, art-templates.

from vim-vsnip.

@hhaoao I think you should treat it as a template and not as a snippet.

Yes, but the way to make the code snippet is the best way to create this template. Ultisnips is very convenient to complete this requirement, I believe vim-vsnip can do it.

from vim-vsnip.

I agree with @hhaoao.

Personally, I think we shouldn't support the ultisnips format.

The ultisnips has a lot of high-level features than vsnip.
So the supporting will be limited in vsnip but the user will expect further support maybe.
For example, I have no plan to implement python interpolation, Vim script interpolation etc.

from vim-vsnip.

@hhaoao i thought to do it one time and save it as a separate plugin, so people can include it if they want.

from vim-vsnip.

@kristijanhusak
If the plugin you write is still a repository of code snippets similar to vim-snippets, then I don't think it is necessary. "Vim-snippets" is enough. You should implement the above template engine so that the code fragments between plug-ins (vim-vsnip, UltiSnips, etc.) can be converted to each other, not just the code fragment archive. Plug-ins that only have a code snippet archive function are of low value. Commonly used code snippets are not as good as imagined. Due to its generality, details, code style and other aspects, it cannot suit everyone's taste. The result is "I downloaded your plug-in, the value of the plug-in is for reference only, used to write your own code snippets".

from vim-vsnip.

Here is a proof of concept for importing ultisnips snippets:

https://gist.github.com/mg979/5c618697c6de65447f628d1f78dade55#gistcomment-3410117

from vim-vsnip.

I planning to add vsnip#snippet#variable#register('DATE', function('s:variable_date')).

It's hard to design... (I want to provide current snippet context for variable resolver but...)

Currently, I don't plan to extend the snippet format now.

But @mg979's idea seems good.

from vim-vsnip.

I have no plan to add the ultisnips format converter.

If it will realize, we should create a separate plugin.

https://github.com/VincentCordobes/convert-snippets ?

from vim-vsnip.

@hrsh7th I did the variable interpolation feature here if you want to take a look:

https://github.com/mg979/vim-vsnip/tree/interpolation

It can also be used to expand non-code variables (just repeated text).

Actual code is here:

mg979@79a7235

But it can be done slightly better (no need to extend the snippet dictionary, for example, just by using the buffer variable that holds custom variables for current snippet).

from vim-vsnip.

Your implementation seems similar to my idea (My idea uses variable to realize the interpolation too).

My thoughts wrote on #93
Currently, I'm worrying to design the variable resolver's argument.

I think we should consider the custom variable resolver as a first instead of interpolation.

from vim-vsnip.

Anyway, I didn't know how to realize,interpolate so it's very helpful!

from vim-vsnip.

Interpolation doesn't need to mean code evaluation, the way I did it is that it can also resolve user variables and insert text without code evaluation:

A variable like $VAR_NAME can be interpolated if the key VAR_NAME is
present in the snippet. The interpolated variable can be evaluated as
vim code, lua code or python code, or inserted verbatim.

So for example:

  "date": {
      "body": [
          "$DATE $DATE"
      ],
      "description": "today's date",
      "prefix": [
          "date"
      ],
      "DATE": "this is a date"
  }

would just insert

this is a date this is a date

from vim-vsnip.

I think interpolation can be done on #94 .

from vim-vsnip.

I don't understand how you're doing it. In my opinion it should work as a regular variable. Anyway whatever.

from vim-vsnip.

In my knowledge, basically, the defined variable's children has no meaning.

So I reuse these children as argument of a custom variable resolver.

from vim-vsnip.

I am simply terrified, man. Why you guys must make simple things hard. Ultisnips code is an overgrown mess, impossible to approach and modify. The previous way the variables script was written was very clean, I had no trouble understanding what was going on. You want to go in Ultisnips direction? Where's the need to change how default variables are evaluated? They aren't supposed to different things than what they were doing before. I guess I'll have to use a custom fork also for this one, sigh.

from vim-vsnip.

IMO, my approach is very simple and keeping consistency.

Because custom variable or built-in variable are the same handling.
vsnip does not care about what is resolver doing.

Whether the resolver internally eval Vim script or just returns selected_text, these will be handled as the same.

from vim-vsnip.

I think the custom variable resolver is the right way.

However, this PR is trying to resolve variables on every sync. This may be unnecessary complexity.

from vim-vsnip.

@mg979 I've created simple version of the PR.
What do you think about it?

#95

It enables to access vim's variable via ${EVAL_VIM:&filetype}.
For example, you can access g:, v:, b: or &filetype variables.

from vim-vsnip.

By the way, VSCode has a variable that does not in the spec too.
So this approach still keeps the spec compatibility, I think.

https://github.com/microsoft/vscode/blob/master/src/vs/editor/contrib/snippet/snippetVariables.ts#L327

from vim-vsnip.

I still think it's terrible. Basically, you want that if you want to use some variable in snippets, you have to register it before with a function call? So you should have a snippet file, but what the variables are doing is defined in a vimscript file somewhere else?

This is:

• totally unnecessary for default variables (like $TM_, $CURRENT_ etc), the way you were doing it before was much better
• very unconfortable for user variables (you can't define them in the snippets file)

About $RANDOM, you could use something from here:

https://vi.stackexchange.com/questions/807/how-to-generate-random-numbers

Anyway my opinions.

from vim-vsnip.

Thank you for explaining your opinion.

I still don't see the problem.

Sorry for my poor English.
So I try to provide the demo as an animated gif.

I don't thought to provide ${EVAL_VIM} as a built-in variable. But I think now, We should provide it as built-in.

from vim-vsnip.

By the way, if user uses this snippet in VSCode, ${EVAL_VIM:&filetype} just inserted as &filetype instead.

from vim-vsnip.

Ok I see now. That's how it's working with the code I've written:

Instead of using, $EVAL_VIM:, I use a variable and define it in the snippet dictionary, and write !vim so that it is evaluated as vimscript. The benefit is that you can also use variables to repeat text. Anyway, as long as it's easy to use I don't care.

from vim-vsnip.

Thank you!
I understanding the benefit.

However, I planning to suggest registering your own custom variable if received a request to implement ruby interpolation etc.
I choose the way of the custom variable for the reason.

from vim-vsnip.

I planning to add the ${EVAL_VIM:...} only.
If the user wants to use python interpolation or lua interpolation, they should register their own custom variable.

from vim-vsnip.

I have no confidence to ${EVAL_VIM}'s naming...

from vim-vsnip.

Maybe just ${VIM:...} ? It's shorter. It looks good anyway.

from vim-vsnip.

Thank you!
I will change to $VIM instead of $EVAL_VIM.

from vim-vsnip.

Hm... we should implement viewer?

Tha actual snippet source still json but VsnipOpen will create editor buffer?

from vim-vsnip.

I was thinking of this solution:

:VsnipEditSnippet [snippetname]

The current snippet file will be loaded in memory with json_decode, then:

• create a scratch buffer with acwrite
• if snippetname is defined, paste the body lines in the scratch buffer
• otherwise the buffer remains empty

You edit the lines as a normal file, when you :w the lines become the snippet body.

• if the snippet existed it's updated
• if not, you are asked for name and prefixes, then the snippet is added to the json file

from vim-vsnip.

Thank you for providing an idea.
Your idea seems sounds good.

My worrying points are

• When we provide a way to create a snippet with custom buffer, the actual source of json will be minified on saving so probably we should remove or modify the VsnipOpen command behavior.

My current thought is it should be good to provide custom snippet format (for only editing, the actual source still json).

// This proposal format can be easy to parse.
// The `snippet(..., %HERE)` will interpretate as json.
snippet(if statement, { prefix: ["if"] }) {
  if ($1) {
  \t$0
  }
}

snippet(for statement, { prefix: ["for"] }) {
  for (var i = 0; i < ${2:length}; i++) {
  \t$0
  }
}

But ... this is too big and maintenance is bit troublesome.

from vim-vsnip.

When we provide a way to create a snippet with custom buffer, the actual source of json will be minified on saving so probably we should remove or modify the VsnipOpen command behavior.

minified you meant modified? I don't think it's necessary to change VsnipOen behaviour. After you edit a snippet in a scratch buffer you would reload snippets, as it happens when you modify and save snippet file with VsnipOpen. But VsnipOpen isn't necessary for this command, it's not necessary to open the snippet json file in a buffer. After you save the snippet maybe it can be opened, so that you see your modifications.

I think a custom snippet format is a bad idea. json has its good sides and we can exploit them.

For example, when running VsnipOpen you can apply buffer mappings, like:

<CR>    edit snippet at cursor position in scratch buffer
<F1>    list snippets and select one for editing

and similar. A custom format is a lot of work and you need extra files. At that point converting UltiSnips files and format would be a better idea I think, you could use your old snippet files.

from vim-vsnip.

No, My means is vim's json_encode/json_decode will minify input json so the VsnipOpen will show the minified json after user uses VsnipEditSnippet.

But I almost agree with your opinion.

Hmm. I'm worried.

from vim-vsnip.

Ah ok I understand. It's not a problem, since it's a single snippet you edit, lines can be modified getting indent level and replacing the body only using the new lines.

from vim-vsnip.

Later I can make this command and show you, then you can decide.

from vim-vsnip.

I gave up on trying to de-minify with custom commands. The PR is #115, but I'm using system python to pretty print the json file, so a python installation is needed for the command. Anyway there wasn't a built-in way to pretty print the json file, currently it is supposed to be created manually, so it's already bad enough.

from vim-vsnip.

@jandamm this is interesting, I wonder if we can create an function from it that will instead formatting the buffer it would copy the json to clipboard or better insert the snippet right away to snippet/ft.json @hrsh7th

from vim-vsnip.

@tami5 my workflow is to copy the code, run VsnipOpen, paste it and then run my command.

It would be fairly easy to copy the selected code reformat it in the clipboard and open the ft.json.

Hardest point would be to figure out where to put the copied code.

I could write this VsnipCopy but a VsnipMakeSnippet would be much harder.

from vim-vsnip.

@hrsh7th What do you think about the VsnipAdd solution which would copy the given range/selection, format it as JSON, place it in the clipboard and open Vsnip?
If you think it's a good solution I'd create a PR for it.

from vim-vsnip.

I did this and it's working well for me.

from vim-vsnip.

@mg979 its seems worth giving it a try. Great work thanks

from vim-vsnip.

#148 was merged now.
It will help to create snippet.

So I'm closing this ossue for now.
If you have other problem or request, you can feel free to open new issue.

from vim-vsnip.