Config for command used to list directory content

[kidonng]

This plugin currently uses ls -A for listing directory content, could you please add a config like FZF_PREVIEW_DIR_CMD in jethrokuan/fzf? This allows using a different program such as exa, lsd, colorls and such to list directory content.

This is what it may look like with exa -a --color=always:

And with ls -A:

[PatrickF1]

Hi @kidonng, thanks for the suggestion. I've been against configurability/extensibility of fzf.fish since I envisioned it. Instead, I favor simple but opinionated code, installation, documentation, plug-and-play functionality, which ultimately means less work for everyone and a lot less work for me as the only maintainers of the plugin.

However, I am starting to change my mind. Both the ls and fd invocations can be configured without too much more work. I'm actually thinking about overhauling configurability for v5, but that's not to come for a few weeks at least. I'll keep this open to remind me.

tl;dr sorry not right now but it's not a bad idea and I'm probably going to do it!

[stephan-hesselmann-by]

Hi @kidonng, thanks for the suggestion. I've been against configurability/extensibility of fzf.fish since I envisioned it. Instead, I favor simple but opinionated code, installation, documentation, plug-and-play functionality, which ultimately means less work for everyone and a lot less work for me as the only maintainers of the plugin.

Note that opinionated code can cause breakage and shifts the work to users, because they need to build around the limitations of the plugin. This makes the plugin more brittle and inflexible. For example, the PR #67 breaks preview for users who link ls to exa.

[PatrickF1]

@stephan-hesselmann-by true. I've always admired opinionated software but perhaps this is the wrong type of software to be opinionated.
Btw, did #67 breaak previews for you? A shortterm fix is to use command ls

[stephan-hesselmann-by]

I think shell plugins in general will attract users who like to tinker a bit. So while I like sensible defaults to get "plug-and-play functionality", I also appreciate some flexibility in configuration. So I like the idea of adding something like FZF_PREVIEW_DIR_CMD with supported default values.

[PatrickF1]

Very true: I can expect fish plugin users to want to tinker. Good job, Stephan, you've convinced me to change my vision for this plugin in the span of 10 minutes.
Alright, that's what I'll be working on for v5: greater configurability. Please give me some time to work on it though. I won't release just configuring ls or fd by themselves because I need to think about it in the context of making everything.
And if there are more things you want configurable, let me know please!

[kidonng]

For example, the PR #67 breaks preview for users who link ls to exa.

Pardon my rudeness, but this is a bad example. exa's website clearly states that it is not a drop-in replacement for ls. And modifying coreutils is generally not a good idea.

That said, I totally agree with your opinion. Having a strong dependence on "third-party" programs (except fzf itself) may lead to more breakages.

[dessalines]

another thing that would be nice to have is not just FZF_DEFAULT_OPS, but FZF_DEFAULT_COMMAND too

So we could do things like

export FZF_DEFAULT_COMMAND='fd --type f'

Related to #66 as I also ran into that issue.

[PatrickF1]

Hey @dessalines, can you clarify what you want to do with FZF_DEFAULT_COMMAND?

[dessalines]

Mainly turn off --follow

[PatrickF1]

Hmm what's tough about using FZF_DEFAULT_COMMAND is that I can't assume the user is using it to find files. They could easily hook it up to browse through a directory of cat pictures and then that would mess up the find file functionality.
However, I think I see now that I shouldn't be using --follow so I'll turn that off.
EDIT: see ac7308d

[PatrickF1]

Hi @kidonng @stephan-hesselmann-by @dessalines, I'm sorry to backtrack but I've changed my mind about making search files more configurable.

What happened was I discovered CLI file managers and I realized they solve a very similar problem of navigating directories, previewing files, and opening them a million times over and in ways better than fzf.fish ever can without me making it a full time job. There are just so many options available I don't really want to add another one into the mix and compete with them when I can just outsource work to them:

• ranger https://github.com/ranger/ranger
• nnn https://github.com/jarun/nnn
• fff https://github.com/dylanaraps/fff
• lf https://github.com/gokcehan/lf
• vimf https://github.com/vifm/vifm
• broot https://dystroy.org/broot/
• midnight commander https://github.com/MidnightCommander/mc
• noice (https://git.2f30.org/noice/files.html)
• and many, many more viable options, esp. if you use Emacs or Vim
  As for myself, I will be using nnn more and more and my search files feature less and less.

I know @kidonng said they can't integrate as well as a native fish plugin but I think the benefits they provide tend to outweigh the benefits that a native fish plugin can.

Another reason I changed my mind is I want to be able to focus on adding features other than configurability into fzf.fish. Configurability might be easy to add, but it can double time for testing as I'll need to test both the default path and the configured path. It can also lead to a lot of questions/bug reports from users caused by misconfiguration which will also sap at my time.

Anyway, however, I realized adding support for exa isn't a big deal and makes sense since exa is so popular, nearly as popular as fd, so I will probably do that.

[PatrickF1]

Hi @kidonng @stephan-hesselmann-by @dessalines. Guess what? I changed my mind! #120