Support passing custom options to each command

[ghost]

Hello!

Great plugin so far, but it would be nice if the functionality provided by the FZF_REVERSE_ISEARCH_OPTS in the jethrokuan/fzf were supported. See: https://github.com/jethrokuan/fzf/blob/master/functions/__fzf_reverse_isearch.fish. I have a (probably) niche use case where I like to have a custom preview window for long history commands when searching through my history but don't necessarily want to export that functionality in the FZF_DEFAULT_OPTS. Having a variable to tweak to add functionality to the __fzf_search_history would be great.

e.g. fzf --read0 --tiebreak=index --query=(commandline) -> fzf --read0 --tiebreak=index $FZF_HISTORY_OPTS --query=(commandline)

[PatrickF1]

Hi @degrix! Thank you for your kind words.

Wow that is indeed a niche case! You got me interested in what you're doing, maybe I'd want to copy it. What do you mean preview long commands? What would you set for FZF_HISTORY_OPTS?

Anyway, I'm currently leaning against it. The amount of extra work to document it and test it is pretty annoying. However, I am open to convincing and it shouldn't be hard for you, the user, to hack it together. May I suggest changing your key binding to this in the meantime? See the FAQ page on the new wiki.

[ghost]

My typical workflow involves making use of a lot of similar, but long, curl commands in my history that typically vary only slightly in their content. Picking which one is correct without being able to see the entire command is difficult without a preview window. I've attached a screen grab as an example of the preview window with a long command. The preview window is always visible even for short commands, be invaluable for long commands.

In the past, I've been bitten once or twice by long commands in the history and choosing the wrong one. Most of the time that's benign, but if the command is destructive by nature, and happens to be tacked onto the end of a chain of commands, it may result in unwanted behavior.

In any case, I've starred the repo and that bind allows me to workaround this issue that I have, so thanks for that!

[PatrickF1]

Thanks for sharing! I may build that into the plugin.

[ghost]

I've been playing around with it, and this is definitely closer to what I was hoping for. So thanks for that!

I think having the --preview-window hardcoded to bottom:3:wrap is pretty opinionated though. It's an opinion I mostly agree with, but has some shortcomings for really long commands. I've switched my local copy over to bottom:25%:wrap to account for this. Maybe you could switch it over to percentages rather than hard coding it to avoid the documentation/testing issue you were originally worried about?

[PatrickF1]

Being able to scroll isn't enough?

[ghost]

The scrollable window is still fairly small for large command stacks; like trying to find the correct variant of a function you're editing in the command history. As far as I can tell, and I may be missing it, to make use of the scrolling you have to use the mouse. With the percentage based approach, I just make my terminal bigger when I know I'm going to be doing something that requires me to search for some of the larger history items.

[PatrickF1]

I see. Okay I'm afraid I'm going to keep it locked at 3 lines for now because most people probably only need 3 and making it bigger is gonna cut off their screen real-estate. Good news though! Next item on my agenda is what this issue is about: allowing everyone to pass in custom opts to each command. So just edit the command for now and wait for that to release.

[ghost]

Great to hear, thanks!

[PatrickF1]

@degrix this has just been released with v6 https://github.com/PatrickF1/fzf.fish/releases/tag/v6.0!