Sure POSIX shell scripting is a good skill to have, but I would hardly consider it good for a text editor to have that skillset be commonplace within their configuration language. Shelling out incurs a non-zero execution cost. For example with Bash, it is significantly slower execing out when using a builtin or parameter expansion will work just fine, especially with these types of quick text manipulation operations. And that's not even mentioning that you are literally starting up a new Bash process every time you want to do something semi-complicated in a Kakouine config. This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative
It is also too easy to write poor shell scripts. It is too easy, even for experienced developers to sneak in GNUisms, and forget simple facts, like how Bash and especially Perl aren't guaranteed to be installed on all systems. Sometimes I also wonder: does Kakoune set `-o pipefail` or `-o errexit`? If somebody sets `ENV` and does something fishy, will that make my text editor unlaunchable? Behavior rooted in common semantics rather than heavy syntax (Bash, Perl) or micro-languages (Awk, Sed) make the overall experience much more pleasant. Especially if you do something like Neovim (Awesome, etc.) and use Lua for Config so you don't have to reinvent anything
> This doesn't just leave a bad taste in my mouth - it is also a giant waste of resources and causes initialization to be substantially slower compared to the alternative
I agree that shelling out on a whim that Kakoune does is a tremendous waste of CPU cycles as the OS needs to construct and tear down a whole process just to do something trivial. Having said that, in day to day usage, kakoune feels quite responsive. It's also easy to hack up plugins really quickly.
Shelling out is a crude way of getting some parallelism also. You might be surprised that constructing a new thread vs constructing a new process in Linux is not that much different resource/latency wise. Since bash/dash code is probably cached in the system memory somewhere already and libc etc are again dynamically shared, it may not be as bad to construct a whole new process. TL;DR it's bad but maybe not as bad as one thinks. It's definitely avoidable and I would not design it this way myself. I remember having to shell out once because kakscript does not know how to increment 1 to a variable and I needed dash to do that! That was one expensive +1 calculation! and I can almost imagine my CPU heating up!
It is also too easy to write poor shell scripts. It is too easy, even for experienced developers to sneak in GNUisms, and forget simple facts, like how Bash and especially Perl aren't guaranteed to be installed on all systems. Sometimes I also wonder: does Kakoune set `-o pipefail` or `-o errexit`? If somebody sets `ENV` and does something fishy, will that make my text editor unlaunchable? Behavior rooted in common semantics rather than heavy syntax (Bash, Perl) or micro-languages (Awk, Sed) make the overall experience much more pleasant. Especially if you do something like Neovim (Awesome, etc.) and use Lua for Config so you don't have to reinvent anything