You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My impression of the --exit-0 and --select-1 options are that they're most useful when piping some custom command into sk, to essentially bypass the TUI and immediately exit if there's 0 or 1 lines piped into sk, and it does this as expected.
What's unexpected is that these options also cause an immediate exit when interactively filtering in the UI as soon as a query is entered that matches 0 or 1 items. This behavior is different than fzf and seems unwanted.
For example, selecting md files in the skim source repo, and then typing c in the query:
Because there's more than 1 result from fd, the UI opens as expected and I can query to narrow things down. With fzf, querying c filters down to the only matching option, but waits for the user to accept it. With sk, the same setup exits the UI immediately upon pressing c (and prints CHANGELOG.md). --exit=0 behaves similarly.
Is this intentional behavior, or a bug of the implementation for these options?
The text was updated successfully, but these errors were encountered:
Since I like hacking on my tools (my main interest in skim over fzf in the first place because I prefer Rust to Go), I whipped together this quick patch that seems to make --select-1 and --exit-0 behave more like fzf.
I'm not sure whether this is a terrible hack or a reasonable path, but the idea here is to keep track of the most matching options that have ever been seen, and trigger the exit on that value rather than the current number of matched options during every heartbeat.
My impression of the
--exit-0
and--select-1
options are that they're most useful when piping some custom command intosk
, to essentially bypass the TUI and immediately exit if there's 0 or 1 lines piped intosk
, and it does this as expected.What's unexpected is that these options also cause an immediate exit when interactively filtering in the UI as soon as a query is entered that matches 0 or 1 items. This behavior is different than
fzf
and seems unwanted.For example, selecting md files in the skim source repo, and then typing
c
in the query:Because there's more than 1 result from
fd
, the UI opens as expected and I can query to narrow things down. Withfzf
, queryingc
filters down to the only matching option, but waits for the user to accept it. Withsk
, the same setup exits the UI immediately upon pressingc
(and printsCHANGELOG.md
).--exit=0
behaves similarly.Is this intentional behavior, or a bug of the implementation for these options?
The text was updated successfully, but these errors were encountered: