Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Alternate parsing of snippets #63

Open
kflak opened this issue Mar 27, 2020 · 5 comments
Open

[FR] Alternate parsing of snippets #63

kflak opened this issue Mar 27, 2020 · 5 comments
Labels
enhancement New feature or request feature request

Comments

@kflak
Copy link
Contributor

kflak commented Mar 27, 2020

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....

@kflak kflak added the bug Something isn't working label Mar 27, 2020
@davidgranstrom davidgranstrom added enhancement New feature or request feature request and removed bug Something isn't working labels Mar 27, 2020
@davidgranstrom
Copy link
Owner

@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
Copy link
Contributor Author

kflak commented Mar 27, 2020

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
Copy link
Contributor Author

kflak commented Dec 2, 2021

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
Copy link
Owner

@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
Copy link
Contributor Author

kflak commented Dec 5, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature request
Projects
None yet
Development

No branches or pull requests

2 participants