[enricozb]

Check out Kakoune[1] for a different take on an editor’s scripting language. It offloads as much as possible to existing Unix tools such as bash, sort, fmt, etc. It uses a clever system of string substitutions that’s a bit unintuitive at first, but not too difficult to grasp quickly. I spent two weeks trying to fix a bug in a Vim plugin that ended up being a 3 line change. After that I felt like I barely understood just a small section of vimscript.

I ended up switching to Kakoune after trying it for a bit because I realized that in the two weeks of me exploring it I had entirely understood it’s “scripting language”, or at the very least understood how to use the onboard docs to write any plugin I wanted to.

[1]: https://github.com/mawww/kakoune

[timeattack]

Sorry, but I find this to be very bad design.

Check this out [1]: kak script evaluating sh script which in turn call perl which constructs kak script commands and output them to stdout to be evaluated by kak.

Or this one [2]: same, as before, but now it's calling awk, which calls `date` binary (so it's kak → shell → awk → date → kak).

It seems that it's done this way because sh is not good programming language to use for manipulating text. Moreover, sh is not good programming language to write complicated programs, which later can be successfully maintained & tested.

For me, kak approach is past the border of unmaintainability.

Also, it raises question of why not to use embedded language like python or lua instead of creating such a limited editor-specific language.

[1]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c... [2]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...

[mawww]

To give a bit of context, the idea behind this design is that those scripts should ultimately only be glue scripts that convert from some editor agnostic tools into Kakoune commands.

I do agree that sh is not a nice programing language, and forking programs all the time is not very efficient. I think that there is a tradeoff between the different approaches, and Kakoune's has proven to make quick'n'dirty very easy while being suboptimal for complex tasks.

I am okay with that tradeoff because I still believe most complex tasks do not need to be editor specific, and should be provided by separate tools written in a more maintainable language.

Another reason is that I've been trying to design Kakoune in a minimalistic way, and one thing I tried to unify was the user and scripting interface, which means I needed a command language that was easy to write interactively (`edit filename` vs `edit("filename")`). This is again a tradeoff that helps with simple things (as users already know the scripting language if they know how to use the editor), while making complex things harder.

[dmos62]

I'm interested in seeing a response to this. I sympathize with wanting to use unix tool composition, but I've personally found shell languages inadequate for more interesting applications.

[epage]

Sounds like you also couldn't run these plugins on windows, if kak even supports windows :(

[wbl]

Or Lisp (ducks)