-
Notifications
You must be signed in to change notification settings - Fork 33
Ideads, suggestions #14
Comments
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. |
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). |
Can you list those? I'd like to look into them
You can source needed files manually, and it will be as official way as it can possible be. |
There's 2 plugs listed on the official site, and there's one pathogen clone. I've tried cloning this pluging manually and sourcing it from kakrc, ran into this: |
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.
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'd like to see what code leads to such situation, because plug.kak essentially loads the files with source command. |
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
Sorry for bloating your issue - I've got it figured out but this might help future users. |
This issue is here exactly for such talks. No problem.
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. |
What do you think: fzf.kak#without-plugin-manager? |
Looks better! In my opinion, still a lot of lines to add to In short, manually sourcing rc/fzf.kak should produce the same end result as |
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 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. |
Suggestion: rename to fuzzy.kak, support >1 fuzzy matcher. Rationale: I've switched back to |
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 |
Seems like fzy doesn't support @supermarin I've added experimental support of fzy in |
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 |
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. |
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. |
I guess |
If you do |
Ah, now I see it. Interesting usage. Seems that fzf doesn't capable of doing this one. Integration of |
Thanks so much for consideration @andreyorst! 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 |
Well, kinda. Yes and no. So there's an example for you:
command will output this, if we pres
You can notice that there's a blank line. That's correct, because we have given an
This way we can pass several
I handle splits this way. And since |
as for supporting multiple fuzzy matchers, lets us have separate issue for that. @supermarin would you might create one? |
@andreyorst Thank you for your hard work for extending kakoune with many awesome plugins! |
@vbauerster Thank you for your feedback, but I'm not sure if it is possible, since there's no child menus, beside And Backspace is used to clear the search pattern, so I don't think you can use fzf's |
@lammermann skim is now supported via |
Thats great. Thank you. |
I can do it for you |
Oh. Thats even better |
@lammermann you can watch for #39 to get notified when it's ready. I'll have time for it in two days |
Despite the fact that I post updates of fzf.kak at r/kakoune and at Kakoune Discourse Board I want to have a single place where Ideas and suggestions can go, so I could have easy track of them. Ihis issue isn't for feature requests, but for discussion of ideas, and overall suggestions to the plugin. If you know what you want and can describe it well please open feature request.
Ideas
I'm not sure how to implement this yet, since there's no kind of history Kakoune in the current state. Maybe parsing specified shell history file, and modifying built-in
:edit
to add files to some history file.Extension of tag search, but with scopes.
Much like builtin grep,but with filtering results by fzf.
The text was updated successfully, but these errors were encountered: