Hi, I am a big fan of Rust and has since moved to sk from fzf. Thanks for the great work.

Before updating 0.8.1, sk was working fine at all. After updating, all of a sudden it just stops working. sk does not have any response. I use fzf side-by-side with sk and fzf is still working as normal.

Using pacman. I removed skim. Reinstall it. Issue persists.

# Start cleanly
bash --noprofile --norc

fzf
# working normally

sk
# no response
sk
# no response
sk
# no response

echo $?
# 101
sk --version
# 0.8.1
sk --help
# Usage: sk [options]
#   Options
#     -h, --help           print this help menu
#     --version [...]
# [truncated ..............................................]

cat /etc/os-release
#    1 NAME="Arch Linux"
#    2 PRETTY_NAME="Arch Linux"
#    3 ID=arch
#    4 BUILD_ID=rolling
#    5 ANSI_COLOR="0;36"
#    6 HOME_URL="https://www.archlinux.org/"
#    7 DOCUMENTATION_URL="https://wiki.archlinux.org/"
#    8 SUPPORT_URL="https://bbs.archlinux.org/"
#    9 BUG_REPORT_URL="https://bugs.archlinux.org/"
#   10 LOGO=archlinux

When running find|sk --bind 'enter:execute(echo {})+abort', skim doesn't always abort.

That is, the selection is printed, then a newline. But the caret stays on an empty line below, skim keeps running, and hitting enter again doesn't get us back to the shell. Typing ctrl-c is needed to end the program.

Tested on Ubuntu 19.04 running konsole, bash 5.0.3 and skim 0.7.0.

I'd like to reuse skim inside my own application. With this, I mean reusing skim as a library. Inside my code, I'd like to pass Skim my sources, hand over control to skim which runs its CLI and once the user selects something, returns the selected items back to me. Mainly these are the features I'd like to have:

• fuzzy finding, including interactivity and options (multi, non-multi).
• providing my own input source, while decoupling the text that is shown to the user from what I get returned.

A possible API could be this:

/// Defined by skim.
pub trait SkimItem: Send {
   /// The text displayed to the user.
   fn display(&self) -> Cow<&str>;
}

struct MyItem {
   .... many interesting fields.
}

impl SkimItem for MyItem {...}

let (tx, rx) = channel::<MyItem>();
// Launch a thread, send MyItems as they are generated into `tx`.
let mut skim = Skim::with_sender(rx, SkimOptionsBuilder::new().multi_select(true).ignore_case(true));
let result = skim.query_user();  // Consumes `sk`.

/// Join the producing thread. `result` is now either an Err or a Vec<SkimItem>, so I know what was selected.

I looked through the code and it seemed like this was not very easy to do right now, since the clap::ArgMatches is passed around instead of option structs and the UI and filtering code is a bit interleaved. Do you think this is a feasible feature request?

It would be nice to be able to ignore certain files (e.g., dotfiles). It would be really nice if fzf-rs could read .gitignore etc (like ack, ag, and friends).

❯ sudo dnf install skim
Last metadata expiration check: 4:59:00 ago on Wed 24 Jun 2020 17:13:12 +0530.
No match for argument: skim
Error: Unable to find a match: skim

It seems the fuzzy matching mode is always case insensitive, and the exact matching mode is always case sensitive.

However, is there any way to get the contiguous matching mode that exact provides (i.e. match whole words) while not having to also match the case? In other words, is it possible to set exact mode to case insensitivity, or smart-case?

For explanation: My use case is full-text searching my notes (with rg) and then searching over the output with skim. Matching the output with the fuzzy matcher mostly shows completely unrelated notes, and exact matching shows the perfect answers except for always having to search for the right case.

examples/nth.rs:

extern crate skim;
use skim::prelude::*;
use std::io::Cursor;

pub fn main() {
    let input = "foo 123";

    let options = SkimOptionsBuilder::default()
        .nth(Some("2"))
        .query(Some("f"))
        .build()
        .unwrap();
    let item_reader = SkimItemReader::default();

    dbg!(options.nth);

    let items = item_reader.of_bufread(Cursor::new(input));
    let selected_items = Skim::run_with(&options, Some(items))
        .map(|out| out.selected_items)
        .unwrap_or_else(|| Vec::new());

    for item in selected_items.iter() {
        print!("{}{}", item.output(), "\n");
    }
}

cargo run --example nth

It generates a match foo 123 although it shouldn't match anything (2nd field consists of numbers, we match on a letter). Am I doing anything wrong?

skim in terminal works as expected

> echo "foo 123" | sk --nth=1 --filter f
foo 123
> echo "foo 123" | sk --nth=2 --filter f
# no output, exit code 1

Using a function like this and selecting some process (just tried random until it broke) as skims' selection produces a panic:

$ fkill
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', 27

function fkill -d 'fuzzy kill processes'
  ps -ef | sed 1d | sk --multi
end

I have sk 0.9.1 and rg 12.1.1 installed, both via cargo-install. Both sk and rg are in my path, and they work well independently. But I cannot integrate them with sk --ansi -i -c 'rg --color=always --line-number "{}"'. Nevertheless, sk is working with grep. ( I don't have ag or ack so I cannot test these ).

Using:

fd --color always | sk --ansi

Displays most colors, but not for current-directory files seemingly, whereas

fd --color always | fzf --ansi

Does what I expect. I'm not sure exactly where this issue is, but I'm noticing it now using this as my default file finder over fzf.

Hi @lotabout thanks for skim I'm enjoying it.

One thing I have wished for is tiebreaking based on the length of the original text, in my case shorter strings are preferred. This lets me select longer strings by continuing to type in Vim rather than use the arrow keys I have included an example below of the default behaviour of skim. In this example lets say we are selecting the build_script_mod directory by typing mod.

Before, just sk:

After, running sk --tiebreak=score,length:

This may accidentally help with https://github.com/lotabout/skim/issues/213.

In the README, it says in installation section that one can head to releases to get ready executables. I went there and there's only zipped source code.

I scrolled down and it seems that back in the day, exe used to come with releases but not any more, can we have them again please?

I use sk as a drop-in replacement for fzf. It worked fine until recently I use zoxide's interactive mode 'zi'. It relies on 'fzf --info' option to work. It would be great to have both rust applications works together.

Benchmark 1: sk --query=hopscotchbubble -e --exit-0 < ../countwords/kjvbible_x10.txt
  Time (mean ± σ):     115.2 ms ±   0.6 ms    [User: 247.2 ms, System: 36.0 ms]
  Range (min … max):   113.6 ms … 116.4 ms    25 runs

...

Benchmark 2: fzf --query=hopscotchbubble -e --exit-0 < ../countwords/kjvbible_x10.txt
  Time (mean ± σ):     119.9 ms ±   6.9 ms    [User: 230.1 ms, System: 63.0 ms]
  Range (min … max):    93.6 ms … 124.4 ms    25 runs

...

Summary
  'sk --query=hopscotchbubble -e --exit-0 < ../countwords/kjvbible_x10.txt' ran
    1.04 ± 0.06 times faster than 'fzf --query=hopscotchbubble -e --exit-0 < ../countwords/kjvbible_x10.txt'

I've made some improvements to sk so its baseline performance (--exact matching) is now comparable to/better than fzf on the M1 for larger inputs (and less than 5% on Intel). sk still lags way behind in fuzzy searches (10%-20% more wall clock time and 2x CPU time).

We also now use less memory than fzf.

I was also able to effectively end the sometimes laggy inputs on searches on over ~200,000 items by moving the matcher to its own thread pool. This is most important to me as now sk is a usable as a daily driver.

And I'm pretty certain I haven't made any breaking changes to the public API.

If anyone is interested, I will merge these changes back into skim. But as it is -- it seems interest is waning -- I may consider a hard fork under a new name.

Crazy respect for how fast fzf is. My guess is two things make fzf still very fast at fuzzy matching on large inputs: 1) as much as it pains me to say, golang is better at/easier for at this type of concurrency than rayon/crossbeam, and 2) the fzf fuzzy algo is amazing (but also may be "cheating"/bailing out somehow on large inputs?).

My question is -- does anyone want to continue, or should I try a fork?

Hi,

Is there any chance to support : in filenames? Having a bunch of files like form:blabla.ini . Field matching chokes on that, because of the : in the filename. execute-silent also chokes (for me) with

--bind 'ctrl-l:execute-silent(/opt/sublime_text/sublime_text {..2}),f3:execute-silent(/opt/sublime_text/sublime_text {..2}),f4:execute(komodo {1}#{2})'

Do I miss something?