Ideads, suggestions about fzf.kak

[supermarin]

Suggestion: rename to fuzzy.kak, support >1 fuzzy matcher.

Rationale: I've switched back to fzf only for this plugin, but might be switching over to fzy because of better matches. It'd be awesome if users could provide a custom oneliner for the fuzzy matcher, the same way you can configure file sources like ag, rg, etc.

[andreyorst]

I have had thoughts about it, but the thing that stopped me back then is that different fuzzy matches have different argument handling options. I rely on --expect really heavily, and the plugin is built around expecting two lines in the result file. If other matches work in the same way and use compatible arguments, it's easy to add them, yeah. Otherwise it will require a new module which isn't hard too. Thanks, I'll rethink this again and notify you if I'll come up with something

[andreyorst]

I've added extended ctags support for all universal-ctags supported languages. I'm not sure if it counts as symbol search, but for now I'll check it as done.

[supermarin]

Suggestion: please officially support installing without a plugin manager. There's already more than 1 plug-like solution, and the official way isn't bad at all (clone/submodule and 1 line into kakrc).

[andreyorst]

There's already more than 1 plug-like solution

Can you list those? I'd like to look into them

officially support installing without a plugin manager.

You can source needed files manually, and it will be as official way as it can possible be.

[supermarin]

There's 2 plugs listed on the official site, and there's one pathogen clone.
Of course, each author will make their plugins installable by their plugin manager.
This is not the ideal scenario, because less advanced users will be tempted to have more than 1 plugin manager (because that's what the official installation steps suggest).

I've tried cloning this pluging manually and sourcing it from kakrc, ran into this:
#30
Loading it with kak-plug works well.

[andreyorst]

well one plug is obsoleted because of mine, and pathogen is just automatization of doing what I suggest you to. And plug. kak is also just doing the loading of everything, but in certain order to workaround the issue that there's no way to make dependencies in kakscript. the order is: load the less nested files first.

Of course, each author will make their plugins installable by their plugin manager.
This is not the ideal scenario, because less advanced users will be tempted to have more than 1 plugin manager (because that's what the official installation steps suggest).

No. I didn't written my plugins to be loaded exclusive by my plugin manager. Instead I wrote my plugin manager in a way that it can load any kind of plugin. This particular plugin is split to parts, so user could control what he needs and what he don't. And since plug.kak can load any plugin, why use another plugin manager? If plug.kak isn't capable of something or you feel that it has some bad decisions or lacking features, just let me know.

I've tried cloning this pluging manually and sourcing it from kakrc, ran into this:
#30
Loading it with kak-plug works well.

I'd like to see what code leads to such situation, because plug.kak essentially loads the files with source command.

[andreyorst]

Example of loading without plugin manager:

[supermarin]

Gotcha; there was no way I could've known you need to source all 3 files without reading the source. I've followed the kak-lsp approach, even the kak-plug approach and sourced only the main /rc/fzf.kak file.

It might be helpful to have

1. installation instructions other than with kak-plug
2. a simplified way of loading it if possible

Sorry for bloating your issue - I've got it figured out but this might help future users.
Thank you for writing the plugin.

[andreyorst]

Sorry for bloating your issue - I've got it figured out but this might help future users.
Thank you for writing the plugin.

This issue is here exactly for such talks. No problem.

Gotcha; there was no way I could've known you need to source all 3 files without reading the source. I've followed the kak-lsp approach, even the kak-plug approach and sourced only the main /rc/fzf.kak file.

It might be helpful to have

1. installation instructions other than with kak-plug
2. a simplified way of loading it if possible

Yeah, I'll add instructions. I've thought that there are something that describes plugin structure, but I was mistaken. Previously this plugin was just single kak script (a 1640 lines kakscript, mind you), and it was so bloated that I've decided to split it apart in the same way, how I've written powerline.kak plugin. And it has such instructions, so when was rewriting README for fzf.kak I've thought that I've added something like this here too.

About a simplified way of loading. I'm not sure if it is possible. There's a discussion on Kakoune's tracker: mawww/kakoune#2402, but it seems that everyone is fine with what we have already, and more complex mechanics aren't necessary. But this also means that plugins that have submodules can't be loaded in arbitrary way unless we specify some order, like I've did in plug.kak.

[andreyorst]

installation instructions other than with kak-plug

What do you think: fzf.kak#without-plugin-manager?

[supermarin]

What do you think: fzf.kak#without-plugin-manager?

Looks better! In my opinion, still a lot of lines to add to kakrc. You might want to make fzf.kak an umbrella file and sorce everything from there. Ideally, loading fzf.kak should be a one liner - the same way as loading plug.kak.
For people who want to custom load only a subset of functionalities, you could still provide the option to source modules directly by hand.

In short, manually sourcing rc/fzf.kak should produce the same end result as plug "andreyorst/fzf.kak"

[andreyorst]

You might want to make fzf.kak an umbrella file and sorce everything from there.

Hm. I've didn't thought of it in this way. Although I don't know if kakoune allows sourcing from script with relative paths but I'll check this. From the first view I think this isn't gonna work, but there's might be a way to workaround this.

Ideally, loading fzf.kak should be a one liner - the same way as loading plug.kak.

Ideally Kakoune community should embrace plugin mangers in a way how Vim community does this. In my opinion. This will allow much more complex and versatile plugins to exist without painful installation.

[andreyorst]

Seems like fzy doesn't support --expect key functionlality, which means that there will be no way to handle splits. I see that fzy isn't capable to show file previews too. fzf.kak is heavily based on fzf features, so making support for different matches means to lose support of those features. What I like about fzf is the amount of possibilities, that are provided with all that command line arguments. Making a generic plugin, but loose features isn't a good idea for my taste.

@supermarin I've added experimental support of fzy in fzy branch, but I don't like the implementation. My code is really messy right now and with fzy support it becomes even more mess. It works, but search in the buffer doesn't work because of incompatibility with fzf

[lammermann]

Suggestion: rename to fuzzy.kak, support >1 fuzzy matcher.

Rationale: I've switched back to fzf only for this plugin, but might be switching over to fzy because of better matches. It'd be awesome if users could provide a custom oneliner for the fuzzy matcher, the same way you can configure file sources like ag, rg, etc.

I like the idea of support for other fuzzy finders. this way I could use skim and provide a module which allows interactive grep searches (seems much harder to me to implement this on the basis of fzf).

[andreyorst]

this way I could use skim and provide a module which allows interactive grep searches (seems much harder to me to implement this on the basis of fzf).

I wonder what's the difference in implementations of this feature for fzf and skim, since skim tries to be as much as fzf as possible. Or I'm wrong? Back when I've checked it was pretty much the same as fzf but with bugs.

[lammermann]

The thing that makes skim interesting for me is the -c option. I've searched for it in fzf but couldn't find something similar. It takes a command (e. g. grep) and gives the input of the fuzzy tool. Than it takes the output of that command as input for the selection list. Its cool for dynamically searching all files in your current directory for some string.

[andreyorst]

I guess grep -r pattern path | fzf is the same as sk -c 'grep -r pattern path', or I understand it in incorrect way?

[lammermann]

If you do sk -i -c 'grep -r {}' it will update the input list every time you press a key. With grep -r pattern path | fzf or without the additional -i option in skim you can't change the search pattern.

[andreyorst]

Ah, now I see it. Interesting usage. Seems that fzf doesn't capable of doing this one.

Integration of skim will be fierily easy since it has mostly capable arguments with fzf. I've just replaced fzf with sk in the fzf command and it works already. But that's not the case with fzy. It's completely different, and other tools like selecta share the same problem - we will loose some functionality of the plugin if we use those.

[supermarin]

Thanks so much for consideration @andreyorst!
I'll maybe look in a couple of weeks when I catch some bandwidth.

I haven't gotten into details of how --expect works, but if I'm not wrong you could not depend on that functionality and replace it with editor's. This way you'd only use $fuzzy-matcher to give you the filename, or any other selection, and then add another key map to split horizontally, vertically, etc.

[andreyorst]

but if I'm not wrong you could not depend on that functionality and replace it with editor's

Well, kinda. Yes and no.

So there's an example for you:

find . | fzf --expect ctrl-q

command will output this, if we pres <ret>:

some/file/that/we/selected

You can notice that there's a blank line. That's correct, because we have given an --expect argument. If we press C-q while fzf is open we will recieve this output:

Ctrl-q
some/file/that/we/selected

This way we can pass several --expects and see what user pressed in the first line.

find . | fzf --expect ctrl-q --expect ctrl-a --expect alt-g ...

I handle splits this way. And since fzf is started in tmux or new X11 window I can't interact with kakoune from it from within fzf. That's why --expect is quite handy, since kakoune can read what action was performed. To make this within editor I'll need to make different commands for fzf, like fzf, fzf-horizontal, fzf-vertical, and fzf-window, which will not be quite the same as it is done now.

[andreyorst]

as for supporting multiple fuzzy matchers, lets us have separate issue for that. @supermarin would you might create one?

[vbauerster]

@andreyorst Thank you for your hard work for extending kakoune with many awesome plugins!
For this one, I've proposal to add Backspace as back, in each child menu to return back to its parent.
For example in fzf-buffer or fzf-file menu pressing Backspace should return to main fzf menu. It's very common when I open fzf-buffer and don't see a file I need, so at this point I'd like to quickly reach fzf-file menu, but cannot, I have to start from scratch.

[andreyorst]

@vbauerster Thank you for your feedback, but I'm not sure if it is possible, since there's no child menus, beside fzf-vcs and fzf-tags, which in fact are just different modes that mimics sub-modes. So there's no place to turn back.

And Backspace is used to clear the search pattern, so I don't think you can use fzf's --expect-key on it.

[andreyorst]

@lammermann skim is now supported via fzf_implementation option.

[lammermann]

Thats great. Thank you.
I'll try to implement dynamic grep. If it works it could be a useful extension to this plugin.

[andreyorst]

Thats great. Thank you.
I'll try to implement dynamic grep. If it works it could be a useful extension to this plugin.

I can do it for you

[lammermann]

Oh. Thats even better

[andreyorst]

@lammermann you can watch for #39 to get notified when it's ready. I'll have time for it in two days