riml
riml copied to clipboard
Minimum and Recommended version of Vim for `riml` generated code
I recently had an issue with compatibility of generated viml run with different versions of Vim. The issue was causing a Trailing Characters error. I narrowed the error itself to to patch 97 of Vim 7.3.
I'm wondering if you've run across similar issues with Riml. For instance in the above case, unless blocks that return early might cause problems. What would be a minimum version of Vim required to use most of the features of Riml? I'm trying to determine what bare minimum and recommended versions to use with Portkey.
Also, I've been meaning to ask you, whether you've written any plugins in Riml. I've been sort of winging it as I go along, so I'd love to see your work!
And If possible could you do a code review of Portkey? I'm sure there are things to improve. As the Inventeur of the language I'm sure you'll spot many silly errors in there. :smile:
Great questions, and no good answers from me, unfortunately.
I don't know much about VimL compatibilities between versions. It's something I really need to look into, or talk to someone who knows more about it than I do, as I don't even know if the language is that well documented from version to version. I should really email @tpope or something :smile:
For this particular bug, I actually suspected something related to string concatenation of callMethod().callAnotherMethod() would cause issues. VimL actually checks types to see if the return from callMethod() is a dict or not. If so, it calls the method on the returned dict, if not it string-concatenates the results of the two function calls, basically turning the expression into:
callMethod() . callAnotherMethod()
I had it marked as an edge-case in my tests: https://github.com/luke-gru/riml/blob/master/test/compiler_test.rb#L2123
What I do currently is leave the code as is, and let the VimL interpreter do its work of tracking types and coming up with the proper solution. I was completely unaware that there was an issue related to this in VimL itself in certain versions of Vim, so thanks for the info :+1:
There's 3 things I can think of that I could do in the situation presented in patch 97:
- Generate compile warnings for every
method().method2()inside aniforunlessexpression that say that if the code is not evaluated, and Vim version is less thanx, there will be a runtime error in Vim. - Wrap every
method().method2()call inside every if expression with a try { } catch { } block that catches the error and logs it. - Investigate the issue more to come up with a workable way to rewrite this portion of code to another that works without patch 97.
Solution 3 is definitely the best, but will take the most time.
Thanks for doing the legwork on the issue, though, and narrowing it down to that patch.
P.S. for a sec I thought Matz was the author of that Vim patch :smile:
Oh yes, and as for plugins, I haven't had the time to write any with Riml, no good ideas from me lately tbh. I will definitely make an examples directory of some Riml examples so that people can look and view what I think of as 'idiomatic' (lol...) Riml.
But I'd be glad to go through both speckle and portkey and create some PRs for things I find.
I should really email @tpope or something
Or @nelstrom. If neither of these two guys know of one, then it's probably not worth knowing. :smile:
What I do currently is leave the code as is, and let the VimL interpreter do its work of tracking types and >coming up with the proper solution. I was completely unaware that there was an issue related to this in VimL >itself in certain versions of Vim, so thanks for the info :+1:
There's 3 things I can think of that I could do in the situation presented in patch 97:
This is good info. So it's about breaking the chain, of curry style function calls. Options 1 and 2 aren't really practical. Once one of these errors happens Vim's red screen of death flashes by, and that codepath is more or less scrambled.
How about rewriting the chain as a series of local variable calls?
defm foo
return get_a().get_b().get_c()
end
becomes,
function! foo
let a_res = get_a()
let b_res = a_res.get_b()
let c_res = b_res.get_c()
return c_res
endfunction
Vim does figure this out by default. The issue occurs only if these calls are inside an if statement that is false. Older Vim(without patch 97) doesn't do this correctly.
From a compatibility pov I think Vim 7.3 seems to be a reasonable target for Riml. I think compatibility features like the above might be good idea to implement or at least put on the roadmap.
Oh yes, and as for plugins, I haven't had the time to write any with Riml, no good ideas from me lately tbh.
Are you telling me Portkey is the first plugin written in Riml?! I'm feeling awfully brave now. ;-)
In hindsight, Most of the issues I've had have been workable. I have always been able to dropdown to viml if need be. And the problem would go away in the next release!
But I'd be glad to go through both speckle and portkey and create some PRs for things I find.
PR's are welcome! If you need clarification about something feel free to let me know.
I should really email @tpope or something
Or @nelstrom. If neither of these two guys know of one, then it's probably not worth knowing. :smile:
Sorry, I can't help. But when it comes to Vimscript I'm no guru.
I haven't seen any other plugins implemented with Riml either, so @dsawardekar is trailblazing with Portkey! I'm looking forward to playing with Riml myself. Nice work @luke-gru!