feat: pre-select stuff with fzf

[caarlos0]

as discussed on twitter (https://twitter.com/caarlos0/status/1443410098471194625), PR adding this feature.

• if input is -, switch right away
• if input is interactive, go through fzf with input as query
• if not interactive, switch as before

implemented on both kubectx and kubens.

PS: would you also be interested in having a homebrew tap that uses the go versions? Right now I'm maintaining my own, but I can port the config here if you create a homebrew-tap repository :)

Cheers!

[ahmetb]

Some questions

1. How do we define this in the CLI --help so that people can tell this is the behavior without having to read the readme? (right now you don't need to read the readme to learn how kubectx works)

2. Should/does this only work if stdout is a TTY (i.e. an interactive shell prompt)? I assume this is not a desirable behavior for scripts etc (though people shouldnt use kubectx for scripts, some unfortunately do)?

3. How/whether can we retain the same behavior if we allow customization to let users use other fuzzy-finder tools through a variable like $PICKER (e.g. #312)?

[caarlos0]

• How do we define this in the CLI --help so that people can tell this is the behavior without having to read the readme? (right now you don't need to read the readme to learn how kubectx works)

hmm, good question... would have to make it a bit more convoluted to explain it properly I believe...

• Should/does this only work if stdout is a TTY (i.e. an interactive shell prompt)? I assume this is not a desirable behavior for scripts etc (though people shouldnt use kubectx for scripts, some unfortunately do)?

Currently its using the same check it does for other fzf commands... so, yea, only on interactive prompts.

• How/whether can we retain the same behavior if we allow customization to let users use other fuzzy-finder tools through a variable like $PICKER (e.g. Adding skim support #312)?

I think that highly depends on the fuzzy-finder... but specific to skim, judging by their docs, it seems it would work...

[ahmetb]

I think that highly depends on the fuzzy-finder... but specific to skim, judging by their docs, it seems it would work...

yeah I think we can live without other fuzzy-finder supporting this feature (and can WARN the user if we don't know how to pass this arg down in case $FINDER is set)

[ahmetb]

something to note is that when/if we introduce a custom $PICKER support, we now have to find a way that users can indicate to pass this $QUERY option in that value. e.g.:

export PICKER="my_picker --arg1 --arg2 _"

and \b_\b would get replaced with the query. Up until now, we didn't have this problem but it's good that we're coming up with this requirement sooner than later down the road.