Yeah I agree it sounds better; it’s like something-enable vs. enable-something somehow.
How would you define arguments for commands?
Something like this?
luadef %{test-hello -params 1 -docstring "asdf"} %{
.... lua stuff ....
}
IMO if lots of people start doing this, we should just make native expansions for alternate interpreters (e.g. py%{}, %lua{}, %perl{}, etc.). After all, luadef test-hello %{...} is just a work-around for doing def test-hello %lua{...}. In general, my stance is that work-arounds are for edge cases, if those cases gain popularity they should be implemented properly as features.
my command supports all Kakoune switches, so you can define arguments too. Just replace perl there with lua and you’re good to go
Any plans to get define-perl-command, define-lua-command etc. into the main kakoune distro?
I found out that I actually never used define-perl-command
1 Like
I always forget something I’m laughing so hard.
Today came across this article on Brace Expansion is demonstrated in 30 programming languages. I was reading @robertmeta work on expansion manual and thought you guys may be interested as you have source code knowledge as well.
And on the same site hit your perl problem @andreyorst Tokenize a string with escaping I know you have a solution another one in the back pocket is always a good thing.
Last thing the site is all solution based no chita chata its pretty cool give it a run has every programming language on nearly every solution. Rosetta Code.
Be good talk latter. Bye 
1 Like
luar plugin by @gustavo-hms got me thinking about custom expansions idea proposed by @bugabinga
declare-expansion lua '/usr/bin/lua'
evaluate-commands %lua{ print("set-option makecmd '" .. os.getenv'kak_buffile' .. "'") }
I’d like to share some thoughts on this:
- expansion behave like functions with single parameter and single return value, therefore custom expansions could be more that simple shorthand for
%sh{!#/usr/bin/lua ...}, - currently pattern
%sh{!#/usr/bin/lua ...},cannot be abstracted because there is no way to return anything from command. For example - in luar plugin there is:luacommand. To return anything from lua code we have to set variable in Kakoune.
Maybe custom expansion should not point directly to some executable, instead they could behave like commands with ability to return single value:
define-expansion lua %{
return %sh{ lua -e '$@' }
}
echo %lua{ print "foo" } # evaluates to echo foo
2 Likes
No, it doesn’t need a real scripting language, Delivering through Diversity.
Consider, if Kakoune had a scripting language you would be set a boring task. Scripts would be undemanding and lack a community of adventures.
I love checking out what new and wonderful way some random community member has bent Kakoune to their will. For me that’s what computer programming is all about and is what I most enjoy about the Kak. ‘So don’t box me in!’.
Song time:
Believe | DMA’S Cover version on triple j Like A Version spotify or youtube
Enjoying the thread. Bye
Warning immature content.
The new kakoune 2020 slogan:
‘If you’re doing the Kak, ya gotta go bareback’
to be honest, existence of countless examples of lisp hackers bending Emacs through Emacs Lisp only, shows that this can be done if editor features it’s scripting language. Though Kakoune approach is interesting in a way that you can use any language you want via shell
‘So don’t box me in!
Very well said, Duncan. I know many people have criticized Kakoune’s scripting model, perhaps it is not “elegant” but it seems great to me. Imagine instead that the scripting language is, say, Python. Well, I hate Python. I know, this is silly, but I can’t stand the lack of closing braces (plus a few other things about mutability). Or imagine that the scripting language is … vimscript!
Can you imagine the hell?
Don’t box me in!
2 Likes
The major downpoint of mostly any language for me is the lack of ability to extend the language to suit my needs. I mainly write C code, and after some time, I’ve noticed that I’m writing a lot of macros that make some things more convenient and useful. And C has worst macro system in my opinion. I also use Rust, and various Lisps, mainly Clojure and Racket, and both Rust and Racket feature hygienic macros, which are awesome ways to extend the language. Clojure’s macros are more like Common Lisp macros, and also are great way to extend the language.
I’m kinda currently at the point when I think that Lisp is the only true way of handling programming. So if you dislike Python maybe you could try out Hy – It’s Python but it’s also Lisp. Recently I’ve started toying with Fennel which is a Lisp on top of Lua, also very interesting project.
The strongest point of Kakoune for me is that I can use anything I really want to script the editor, will it by Python or Hy, Lua or Fennel, Java or Clojure. In only comes down to using appropriate tool for the task. But if editor features the language that I can bend to my will, like Lisp, I don’t think that this is really a big deal anymore.
1 Like
Yes, that’s exactly the point. Yet there still is misinformation around, I remember posts on reddit with people claiming that the “scripting language” of Kakoune was “bash”!
1 Like
Well, I suppose it depends on what are your needs and your environment. I think there is a reason why most large companies don’t use Lisp or don’t use it as heavily as other languages.
Seeing that you like C but need macros I can only say try C++. It’s a very powerful language, and template metaprogramming is as capable as lisps macros. You’ll probably want to check c++20 if you want to know what’s coming in that regard.
Regarding boilerplate code… that’s why I look for a good editor. I think it’s irrelevant how many characters do words have once you have a good IDE that will do that stuff for you (via snippets, code generation, or whatever).
In general, I think the programming of big programs is more a problem of design.
Completely true!
Although when it comes to plugins, I end up installing a language environment in my pc to run just a single program 
.
Well, ackchyually, this is probably due to The Lisp Curse. Lisp was very popular language up until certain point. And environment really not a big deal – there are lisps for microcontrollers, for heavy parallelled systems, for embedding, games were partly written with Lisp, like Crash Bandicoot for example. There’s a famous quote:
The problem is, as I see it, that Lisp is so versatile, that most developers who do not use it, think of Lisp as it is Jack of all trades, but it’s not entirely true.
It is somewhat funny, but the the Lisp curse article has this:
And this is technically true. Lisp had object system way before Java was developed. I use C++ at work and, though I’m locked to old C++ I’ve also studied new standards, and I, personally, hate C++. It’s just not right as a language. Mostly because of enormous baggage of backwards compatibility. Professional C++ hackers may find all these features useful, but I don’t think these are really necessary. The thing is, that with rich macro system, probably 70% of all C++ features could be added without integrating those into compiler directly. Rust kinda does it. And I do so in C, and I like it more than C++ 
This is not what I generally agree with. Generally IDEs smartness is the result of cumbersome language design. I have no problem with semantic autocompletion, but sometimes I often thing: “damn… all of this requires 7x less code in Clojure”, yet we praise IDEs for generating 7x more code for us, so we don’t have to type it ourselves. Editor should be good at manipulating text, but generation should be really done by the language in my opinion. This is what macros are for in the end.
The truth is, that there are always trade offs so there’s no silver bullet in programming. But I think that it is also true that Lisp was closer to be the silver bullet than any other language.
1 Like
Now when I think of it, why Kakoune does not have this kind of thing? Shebang %sb{...} expansion could be very useful, and we will still leverage shell to evaluate it. @mawww have you ever concerned something like this?
evaluate-commands %sb{
#!/usr/bin/lua
...
}
evaluate-commands %sb{
#!/usr/bin/perl
...
}
2 Likes
I believe that’s a feature. It may also be a reason to use it.
I understand the love you have for LISP. But I find it similar to the love many programmers have developed for python, for multiple reasons as well. It’s just that people have different tastes, and writing less code (assuming that’s the case) may not be a priority.
1 Like
I believe that’s a feature. It may also be a reason to use it.
Backwards compatibility is not a problem if the design is correct. In my opinion, C++ is not the best example of good of backwards compatibility design (and language design in general). My problem with C++ is that it is constrained by its past. Anyway, I’m not C++ guru by any means, and I understand the great value of this language, I just kinda disappointed by design choices.
I literally see no situations where more code would be better than less code for the same task. The more code you have, the more code you have to read, verify, test, debug, maintain, and refactor. Imagine if you could do exactly what you do but, say, with 9x less code, without difference in performance, would you ever want to go back to 9x more code in the first place? This is why I think that all these new languages that are competing with C++ such as Zig or Rust are good opportunity and should get more traction and contributors.
I agree with what you say, and I’m a bit overreacting towards C++ (mainly because I write SOC emulation at work in old C++, and experience is very unpleasant)
Guile could be used for extending Kakoune if one really needs it and wants to figure out how to get that to work.
I feel like the define-perl-command andreyorst gave and the pydef from kakoune-easymotion are examples of what you could do to extend Kakoune more (or less) elegantly.
2 Likes
Thats quite an interesting idea, I wonder if the shebang system is exposed in any way by the unix api, or if its strictly file based…
1 Like
Traditionally, the shebang is handled specially by the kernel. The Linux kernel specifically supports custom “binfmt” definitions, so that executables that begin with #! will be launched by the named interpreter and ELF executables will be launched by the dynamic linker (typically /lib64/ld-linux-x86-64.so.2). files that look like Windows executables will be launched by /usr/bin/wine, etc. But useful as it is, it’s all very platform-specific.