fzf-contrib

[lazywei]

As @junegunn suggests in #84, let discuss more detail about how to organize useful snippets for users. A fzf-contrib would be great. Any other thought?

[junegunn]

Thanks. Currently I only have a very cursory idea of how it should be done. But here are some things we have to think through.

Project structure

bash, zsh, and fish all have different syntaxes, and we have to partition the snippets, either by using directories for each shell,

fzf-contrib/
├── README.md
├── bash
│   └── xxx
├── fish
│   └── xxx
├── vim
│   └── xxx.vim
└── zsh
    └── xxx

or by using different extensions

fzf-contrib/
├── README.md
├── shell
│   ├── xxx.bash
│   ├── xxx.fish
│   └── xxx.zsh
└── vim
    └── xxx.vim

We already have bash completion in this repository, but we could put more completion functions in contrib repo as well.

Naming convention

Each snippet should be given a unique, unchanging name. We should have some kind of consistent naming convention for each snippet.

Renaming

But the user may not like the convention so I think we should provide some helper function for loading the snippets and renaming them as desired

# This will script load xxx function
source ~/.fzf-contib/shell/xxx.bash

# Optional second parameter for renaming it
fzf-contrib-load xxx yyy                # Load xxx.$SHELL, and rename xxx to yyy

Documentation

It would be cool if we could see the list of the snippets and the description of each directly from shell (like a man page maybe?)

fzf-contrib-help
fzf-contrib-help xxx

[lazywei]

As for project structure, I would prefer the latter one as it is more clear to me. As for naming convention, could you give a more specific description? I like the idea of fzf-contrib-load and fzf-contrib-help.

[junegunn]

I haven't really given thought about the naming convention, but I'm just stating that we need one. Well, take a look at the functions in the wiki page. Some start with f-prefix, some don't. And they usually have very short names, which is convenient if you're the author of the function who knows exactly what it does, but it's really hard for somebody else to see what it is for just by looking at the names. (fe, fs, fd, cdf, fbr, ...). One approach we can take is to give them long, explicit names, and let the user loads them with short aliases.

fzf-contrib-load tmux-select-session fs
fzf-contrib-load git-checkout-branch fbr
fzf-contrib-load git-checkout-commit fco

[lazywei]

Hmm.. I feel that too. In addition, I think the names should be somehow "exclusive" to prevent collision. With that in mind, I think f-prefix is good. I think making explicit names and leave the alias or mapping to users is good!

[lazywei]

I started a repo at fzf-contrib.

Since some shell scripts are the same in bash and zsh, how should we organize such snippets? For example

# fkill - kill process
fkill() {
  ps -ef | sed 1d | fzf -m | awk '{print $2}' | xargs kill -${1:-9}
}

can be used in both zsh and bash. Then where should we place it? Or should we add a common/ folder under the shell/ to keep these shared snippets?

[junegunn]

Thanks for taking the initiative. You could use a symlink in that case, but I'm not sure if it's the best way to do it. Well, since you're the maintainer of the project, it's totally up to you to decide how to organize stuff. You don't even need to follow the ideas I mentioned in the above comment :) Just let me know when you think the project is ready for release. We could mention it on the README page or on Wiki.

[g0xA52A2A]

Would a github organization perhaps be an option? Something like this tmux organization https://github.com/tmux-plugins for example.

This would allow for separate repos which is useful for things like vim plugin managers. I've created a repo which is essentially a mirror of the vim plugin in this repo with some minor additions purely to better integrate with my dotfiles.

[junegunn]

@george-b I'd thought about it. But felt that it would not be very useful to many, as everyone has different tastes and needs. So we would have to provide stuff that can be heavily customized, but then again, most of the stuff have only a few lines of code, so doing so can be an overkill or too much work at the same time. So, I'm currently okay with the current way of sharing examples on the wiki page. I have a feeling though, that the page is getting too long. We may need to split the page into sub pages.

[g0xA52A2A]

@junegunn I suppose the vim plugin is the only complex thing, as you say the other snippets are fairly simple. :+1: for breaking up the wiki though.

[lazywei]

@george-b @junegunn

Sorry I totally forgot this issue ...

I'm somehow against placing snippets in wiki as it's not easy to maintain them (without version control, and modification management). Either placing them into fzf repo, or using fzf-contrib to contain them would be better, IMHO.

By the way, @george-b , if you'd like to, maybe I can add you as fzf-contrib's collaborator, and then we can transfer the snippets to that repo?

Thanks.

[junegunn]

@lazywei @george-b I see it differently now. For me, they are just examples to give the idea of what can be done with fzf, so I don't think strict version management is really required. I want the users of fzf to creatively come up with their own solutions to their problems on their environment after skimming through the examples, instead of just picking up random stuff without fully understanding them. In the sense, I think wiki pages, blog posts or video screencasts should suffice. Anyway, that's just my idea.

[d630]

Hey, if someone is still interested in "organizing" code snippets around fzf, have a look at this. It's simply a first draft (or something like that). Feel free to fork and modify it to your needs.

[teto]

@D360, thanks for the initiative. I like the way ctrlp snippets do things. If you want to filter on registers you can install the plugin 'ctrlp-register' and then add it to the list of authorized ctrlp plugins. IMO the contrib folder could split the snippets into several repositores "fzf-registers.vim", "fzf-marks.vim" what do you think ?