[mawww]

Hello,

Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ?

The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actually targeting POSIX shell.

The rational behind this extension model can be found there: https://github.com/mawww/kakoune/blob/master/doc/design.asci...

And a more in depth explanation on how to use it is there: https://github.com/mawww/kakoune/blob/master/doc/interfacing...

[Direct]

Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular:

> We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).

I don't really want to switch to an editor where missing options might have to be justified. I'm not knocking your work, it's really good, and my complaint applies to vim as well. But if I can't implement something myself as an add-on (which I definitely have more power to do in vim) and have to wait for it to be patched and released in your release cycle I'd rather just try and implement your features in vim and keep the customisability.

Having said that I could be wrong and maybe the plugin system is more powerful than I thought. But as an example, I have a 5 line function letting me have ctrl-p like functionality backed by fzf in vim. I can't figure out how I would do that in kakoune at all.

[mawww]

Thanks a lot for you reply, I try to be reactive to feature requests, especially easy ones like making something configurable through an option (I expect most of these to be resolved in a day or so).

Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.

[Direct]

Yeah, I can't see how I would do it. I could open a tmux pane with fzf and run another kak window but that's not really the goal. I'd like to use fzf to open a found file in the current kak window. The plugin architecture just really limits this kind of thing, and this fzf example was just a simple one I wanted to use to demonstrate the point.

But again, the stuff you have in this editor is absolutely fantastic, really, I can't say that enough. I just personally find kak less flexible than an already inflexible vim so I couldn't stay with it.

If you have a way to do the fzf example though I'd be curious to see how you do it.

[mawww]

Thanks a lot for you feedback, if you use tmux, interacting with fzf is easy as you can run fzf-tmux, that will open a tmux pan for fzf to run in.

There is an example script for that in https://github.com/mawww/kakoune/issues/383

Its more tricky if you do not use tmux, as due to Kakoune client/server nature, fzf will be launched by the server, which might not even have a terminal. That said I really enjoy fuzzy matching, and most built-in completions do fuzzy matching already.

Thanks again for giving feedback on your experience with Kakoune, always much appreciated !