davidgranstrom / scnvim

Neovim frontend for SuperCollider.
GNU General Public License v3.0
203 stars 28 forks source link

[FR] Alternate parsing of snippets #63

Open kflak opened 4 years ago

kflak commented 4 years ago

It would be really handy to have an option for arg lists in snippets to be divided by \newline, like this:

SinOscFB.kr(
    freq: 440.0,  
    feedback: 0.0,  
    mul: 1.0, 
    add: 0.0
)

instead of this:

SinOscFB.kr(freq: 440.0,  feedback: 0.0,  mul: 1.0,  add: 0.0)

However, it would be a bit unfortunate if this would have to be set globally, so if there is a way to select this behavior per snippet would be very, very nice.

Another thing I was thinking about, which may merit its own issue, is that most of the time I would like to keep the argument descriptor when punching in values. Now they disappear when I write in. This is something I would be happy to set globally. Maybe this is already possible? I am using UltiSnips with Deoplete....

EDIT: Sorry about the bug label, not sure how to get rid of it....

davidgranstrom commented 4 years ago

@kflak It would be simple to generate two versions of each snippet, one split on newlines as the example you posted. However, this will also make users have to choose between the two alternatives when expanding each snippet. Maybe this can be configured in the snippets engine somehow, there could be another keybinding for this perhaps.

Keeping the argument description would also be easy to implement. This could be a user setting as you mentioned. Another feature I've been thinking about is to have a setting to not include mul: 1, add: 0 in the snippet, since this can be accomplished easily outside of the method call.

kflak commented 4 years ago

I'm just starting to wrap my head around UltiSnips, so I don't know too mch of how this would work, but I like the idea of setting up two different keybindings, one for each alternative. And dropping mul and add from the snippets would be very nice indeed :-)

kflak commented 2 years ago

Hi,

Just wondering if there has been some movement on this? Otherwise I'd be happy to get some pointers on how to do this myself, so that I could possibly contribute a PR :-)

davidgranstrom commented 2 years ago

@kflak There has been some discussion recently with the merge of the luasnip snippet format. I would like to include options for snippet generation in this PR

I'm still not so sure how we would handle (autogenerated) mutli-line snippets transparently though, afaik this is not something I've seen before. The only option that I can think of at the moment is to have two version of each snippet and let the user select. This would double the amount of snippets generated though which is already quite extensive..

What I envision is to have different formatting options for snippet generation, maybe different styles e.g. compact, and ignore mul/add would be nice. Maybe multiline could also be an option?

With that said, another possibility would be to write a small function which expands a single line statement into a multiline after the actual snippet has been inserted. Something like this (note not extensively tested, cursor needs to be placed before the opening ( for this to work)

--- Split a single line function call into one parameter per line
function split_single_call()
  local lnum, col = unpack(vim.api.nvim_win_get_cursor(0))
  vim.api.nvim_buf_set_mark(0, '<', lnum, col, {})
  -- find the open paren
  vim.cmd[[normal! f(]]
  vim.cmd[[exe "normal! a\<cr>"]]
  -- find the closing paren
  vim.cmd[[normal! f)]]
  vim.cmd[[exe "normal! i\<cr>\<esc>k"]]
  -- perform the split
  vim.cmd[[s/,/,\r/g]] 
  lnum, col = unpack(vim.api.nvim_win_get_cursor(0))
  vim.api.nvim_buf_set_mark(0, '>', lnum, col, {})
  -- reindent
  vim.cmd[[normal! vgv=]]
end
kflak commented 2 years ago

This is great, I'll give that function a go at some point in the near future! Thanks for the tip.