Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[Feature Request] Add conditional control statements to kakscript #2777
I think some more control statments should be added to kakscript.
In some pluggins I have seen, there are shell expansions solely for the purpose of a conditional operation, which is a performance drop over a native kakscript
I'll admit, many things in in kakscript won't need native conditional logic, since they'll be calling the shell anyway for some other purpose. That, and the performance impact is small enough (order of 1ms) that in most situations this is a non-issue. But for situations where conditional logic is all that is needed -- such as settings in plugins -- it seems like a waste to call the shell just for that.
Add bash-style conditional statments as kakscript commands:
@Delapouite in my (limited) experience, spawning a shell scope with dash has about 1ms of overhead. It's likely several times that with bash. Inside the shell scope, builtins are for the most part free, and process calls have their own overhead, with the unavoidable (but not negligible) process spawn. Even a basic
I think this would be acknowledging the failure of Kakoune's extension model, as we could not plausably deny that Kakoune's command language is a scripting language... (Its already ambiguous, the try / catch construct allowing a limited form of flow control already).
It would also be pretty limited, as I can only see two usefull things expanding to true or false:
In order to fix that, we would need to extend the command language further to introduce "expressions", as we currently only have statements. This would be a huge change in the extension model.
Out of curiosity, what do you use RawKey for, and in particular, cant the condition be encoded in the RawKey regex filter ?
Thanks for the replies.
I don't know of a way to measure the performance impact, but from my observations it is in the order of 1ms, as @occivink said.
The application I have noticed this in is the kak-crosshairs plugin pull #11.
@mawww For an implementation idea, would it be better to compare the expansion result to the empty string
So, I understand now that making a new scripting language is one of Kakoune's non-goals. After all, we don't want to just end up with a bad clone of vimscript (which is already bad).
If this interpretation is correct, could it be added to design.asciidoc or faq.asciidoc?
referenced this issue
Mar 12, 2019
IDK if it is the intended use, but I've sorta been using options like this: using logic in a shell expansion to determine a command at config time, and store it in an option to be evaluated later.
I like it: a simple addition. And it would be really helpful for conditional plugin and filetype configuration.
This still, however, has the question: how far should we develop kakscript as a language vs. supporting an alternative extension model vs. just saying "No, you can't make Kakoune do X"?