Possibility to support skim

[mnacamura]

Hi, first of all many thanks for creating this nice plugin!

skim is a clone of fzf written in Rust. I use skim in my daily life and wish for skim support by any chance.

fzf and skim have compatible interface, so it is easy to adjust fzf.fish to skim:

• Use environment variable SKIM_DEFAULT_OPTIONS in place of FZF_DEFAULT_OPTS.
• Use command sk in place of fzf in functions/_fzf_wrapper.fish

Actually I forked fzf.fish [here] in which the above adjustments are done, but IMHO it would be nice if fzf.fish has an option to use skim in place of fzf. I see adding another option will increase maintenance costs, so I'd like to hear your thought.

[PatrickF1]

Hi Mitsuhiro! Interesting, this is the third request to use skim (for some reason I can't find the other two 🤷‍♂️).

I see adding another option will increase maintenance costs

Yes, this is a major reason I haven't done it despite the other two requests.

fzf and skim have compatible interface

However, if skim does plan on always conforming to fzf's interface, then I can consider supporting it. Do you know if this is the case though?

[kidonng]

I once did something similar: jethrokuan/fzf#168

The point is they are different projects. Everyone can write their own "fzf", there is no such assured "compatibility" when it comes to niche usages, where fzf shines the most.

The "compatibility" you mentioned can be easily achieved:

• set -x FZF_DEFAULT_OPTS $SKIM_DEFAULT_OPTIONS. No, there's nothing wrong about this.

• Write an alias of fzf:

  function fzf
    sk $argv
  end

  Note there could be potential issues this way: Can't read pipe to function fish-shell/fish-shell#206

  A better way would be to symlink sk to fzf and add it into your $PATH.

[PatrickF1]

Yes, if I decide to support skim and skim diverges from fzf, I'll be on the hook for making fzf.fish compatible with both. That'd be unimaginably painful. Besides that, I don't want to support skim because

1. this plugin is fzf.fish, implying it's particular to fzf and not any other fuzzy finder and I am not open to renaming it
2. I personally don't use skim so it'd be hard for me to keep up-to-date about skim and test it with each change
3. I don't have a ton of bandwidth to support something like this and the advantages seem pretty limited given people can try symlinking sk to fzf themselves

[mnacamura]

Thank you guys for your valuable responses. After searching for any pieces of information about their stance on the compatibility in skim's repository, I could not find that.

I agree that creating symlink should be the easiest way. For my personal preference, I don't want to expose the symlink and the environment variable to global scope. If fzf.fish were a monolithic script, I would make a wrapper in which path to the symlink and the environment variable are passed to fzf.fish. However, it isn't, so it's uneasy for me but this is just my personal issue.

Anyways, I'll find my best solution. Thanks!