[Feature request] fzf integration

[mattdkerr]

Suggestion

fzf clink integration in cmder shell

Use case

No response

Extra info/examples/attachments

https://github.com/chrisant996/clink-fzf
or
https://github.com/chrisant996/clink-gizmos

Checklist

• I have read the documentation and made sure this feature doesn't already exist.
• I have searched for similar issues and found none that describe my feature request.

[DRSDavidSoft]

@chrisant996 Can you please give a short list of requirements for implementing this in Cmder, if any? How much additional space would you estimate this will require?

[DRSDavidSoft]

I also found this interesting gist for using fzf for history:
https://gist.github.com/rupeshtr78/ed42a23aec87b8463e4f04bec0308d63

[chrisant996]

It's covered in detail in the docs here: https://github.com/chrisant996/clink-fzf/#fzf-integration-for-clink

Note the settings and key bindings.

Here is a quick summary to get you started:

@chrisant996 Can you please give a short list of requirements for implementing this in Cmder, if any?

These things are needed:

1. Cmder would need to include fzf.exe (available from fzf).
2. Cmder would need to include fzf.lua (available from clink-fzf).
3. But before Cmder can include fzf.lua, I will have to make some changes to the fzf.lua script. Otherwise when Cmder includes the script it will interfere with everyone who is already using clink-fzf or clink-gizmos, and it will cause errors (it wasn't designed to have multiple copies of it all loaded at the same time, and if Cmder includes it then that will start happening for all Cmder users who were already using clink-fzf).

How much additional space would you estimate this will require?

The size of fzf.exe, which is around 4 MB.

I also found this interesting gist for using fzf for history:
https://gist.github.com/rupeshtr78/ed42a23aec87b8463e4f04bec0308d63

No, don't use that:

Clink-fzf already has support for fzf history. The cited gist is missing all of the rest of the fzf support. The gist appears to be only trying to change clink-fzf's history implementation to print "Searching History" first, but it has bugs in how it tries to do that, and it won't work properly. (And the official fzf support in other shells doesn't print that.)

[chrisant996]

Also, if you make Cmder by default enable the fzf default key bindings, you'll receive complaints about Tab no longer working as expected. Anyone who has bound Tab to any of the completion commands other than complete (e.g. menu-complete or clink-select-complete, or setting clink.default_bindings to windows) will suddenly experience Tab no longer working how they wanted.

I'll try to make the script do its best to compensate for that. It'll probably be able to "magically" do what people expect for 99% of users, but in some fancy custom configurations it may still interference.

[DRSDavidSoft]

@chrisant996 Thanks, in addition to that, I believe it would be best for the "conflicting" features to be opt-in and enabled through some sort of config, and instructing users to use a command line text editor to enable those that they'd like.

Clink already has an excellent mechanism to enable/disable configuration through its set subcommand, we need to put more emphasis on that in the Cmder's README as well, in my opinion. Many users are missing all the great Clink features that you have developed, it would be awesome to include most of them in Cmder since they will not really introduce a noticeable size difference in the final package as well.

[DRSDavidSoft]

fzf should be included in the Cmder full package (which already includes git). The lua scripts in my opinion are just as important as the clink-completions package and very lightweight.

[chrisant996]

@chrisant996 Thanks, in addition to that, I believe it would be best for the "conflicting" features to be opt-in and enabled through some sort of config, and instructing users to use a command line text editor to enable those that they'd like.

The fzf integration in fzf.lua is opt-in; it's off by default (see its readme.md for more info).

I had interpreted the original request as "enable fzf integration by default".
If the plan is to merely to add the ability to enable fzf integration without needing to manually install additional files, then that seems fine -- although in Cmder's documentation it should probably call out how to enable the integration and what the side effects can be. And it should include a link to both the clink-fzf readme.md and to the fzf repo, for more info about usage and configuration and capabilities.

Clink already has an excellent mechanism to enable/disable configuration through its set subcommand, we need to put more emphasis on that in the Cmder's README as well, in my opinion. Many users are missing all the great Clink features that you have developed, it would be awesome to include most of them in Cmder since they will not really introduce a noticeable size difference in the final package as well.

I noticed that a change was made to turn on match.expand_envvars.

But I think instead Cmder should be using default_settings (and maybe also default_inputrc) for defining defaults. That way defaults can be changed without requiring any fancy scripting or conditions or special commands.

See notes under Files.

Cmder could simply include a file default_settings in the vendor\clink directory, and any values listed in it would override the built-in defaults. And if a user runs clink set name=value to set their own value for a setting, then the user configuration supersedes whatever default was listed for that setting in the default_settings file. I.e. the precedence order for each setting is (1) a value set by user, (2) a value in default_settings, and lastly (3) the built-in default value.

[DRSDavidSoft]

Good points, also I like the idea of the lua scripts being able to deal with multiple instances being loaded from multiple places, since there are users who unknowingly install both. The integration can be made after handling such cases are made within the code, in the meantime I'll read the documentation to better understand how each feature works and what we can offer to first time users, as well as "pro" users who have been using Cmder/clink for some time. Clink really is the best shell on Cmder! 😄

[chrisant996]

I like the idea of the lua scripts being able to deal with multiple instances being loaded from multiple places, since there are users who unknowingly install both.

On the surface, it sounds great, right? If all the different copies are identical, then it's great, right? But in reality, the different copies will usually end up being different. And then things get confusing and weird and problems happen and people report bizarre issues that take many hours to track down.

After doing some work to prototype "multiple versions coexisting", it's a bit of a mess (as should be expected), and there's no way to make it fully reliable for all kinds of duplication situations.

I'm leaning towards adding some Lua code in Cmder that loads a built-in copy unless another copy is loaded. That would make it so Cmder comes with built-in fzf support, but if a user has installed clink-fzf or clink-gizmos then the user's version gets used instead. It's easy to make that reliable.

Does Cmder plan to include fzf support for powershell, git-bash, etc? Or will it be only for cmd/Clink?

[daxgames]

Just mu $.02. Keep in mind I have no idea how to do it for one shell much less all of them, I just think if we do it for one, we should do it for all. The same fzf.exe should work for all I would think.

[chrisant996]

The same fzf, yes.

But the integration is different for each shell.

If the goal was "just run xyz set fzf_integration on and viola", then no, that isn't realistic unless someone wants to write a special xyz program that knows all the shells and can configure (and un-configure!) fzf for all the shells at once.

And I think that's also a mark against configuring Clink in a way that's too different from how powershell/etc behave.

If Cmder's goal is to provide an environment where all the shells behave the same, then that has to cater to the lowest common denominator and also avoid things that involve a bunch of configuration.