-
Notifications
You must be signed in to change notification settings - Fork 90
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
add CUE initial support, based on js.vim #209
Conversation
autoload/sj/cue.vim
Outdated
" built-in js indenting doesn't indent this properly | ||
for l in range(lineno + 1, lineno + len(items)) | ||
call sj#SetIndent(l, indent + &sw) | ||
endfor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seem to have added manual indenting since standard js indentation doesn't work right here. Is there existing CUE indenting in Vim or external support? It might be that removing this will still produce good results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right I missed that point. CUE have a fmt
command, and there is vim-cue/indent that paraphrased JSON...
ftplugin/cue/splitjoin.vim
Outdated
" in CUE, trailing comma means something else | ||
let b:splitjoin_trailing_comma = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of setting the variable, you could remove the check for it in the code. Or is that variable used in settings by one of the parsers or something?
Looks good, thank you for your work and for the kind words :). I've left a few comments about code that might be unnecessary, could you check them out? Additionally, could you add a short documentation section with examples of the functionality? One line in the table of contents here, after CSS, I think: splitjoin.vim/doc/splitjoin.txt Lines 9 to 34 in 3e60a0b
And a section that you could copy from the one above, but with three simple examples for the kinds of structures that are being handled: structs, arrays, and arguments, no need for edge cases, just a hint at what users could try: splitjoin.vim/doc/splitjoin.txt Lines 330 to 357 in 3e60a0b
I'm happy to help, you could open an issue with some examples of how you'd like it to work, but I'm pretty busy with other things these days, so I can't promise when I could get around to them. If you'd be willing to try to make them work with PRs, I can give advice and try to point you in the right direction. There should be similar languages you could start from, similar to how you based this off of javascript. |
Thank you, actually I'm also not sure I can work so much on this soon. This was more of a quick hack, but maybe the "configuration" community will come :)
Yes! CUE is heavily inspired by Go, but still have some quirks. I can try to think on some syntax for an "umbrella" issue. |
Alright, I see that you've also started working on imports, but since you mention you might not have the time to work on it soon, I'll merge what we have so far, and you could continue in a separate PR when you have the time. |
Hello,
Thank you for your plugin !
Here is a first basic support for the CUE language. Basically I want to splitjoin
[ 1, 2 ]
,f(a, b)
as javascript and{x, y}
as go structs, ie removing commas when splitting{ ... }
. So what I did isautoload/js.vim
for Arrays, Args and ObjectLiteral,:%s/#js#/#cue#/g
,1. Handle comma removal/addition
2. Change to
OneLine
instead ofAroundCursor
(because structs are first class, but this should be configurable)3. Keep
sj#ParseJsonObjectBody
to parse structs when embeddeddelimiter_padding
tos:SplitList
to handle both:1. Padding on lists, e.g.
[ x, y, z ]
2. No padding on arguments, e.g.
f(1, 2)
As a quick example :
splits to
and at the second level
I'll leave support of
if
,for
,let
comprehensions for later but it could be nice too. CUE is very flexible on whitespace, so we could actually go far like splitjoining infix operators or whatso.