-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
@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 |
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 |
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 :-) |
@kflak There has been some discussion recently with the merge of the 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. 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 --- 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 |
This is great, I'll give that function a go at some point in the near future! Thanks for the tip. |
It would be really handy to have an option for arg lists in snippets to be divided by \newline, like this:
instead of this:
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....
The text was updated successfully, but these errors were encountered: