[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignoring files #3

Closed
Stebalien opened this issue Jul 1, 2016 · 9 comments
Closed

Ignoring files #3

Stebalien opened this issue Jul 1, 2016 · 9 comments

Comments

@Stebalien
Copy link

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).

@Stebalien
Copy link
Author

Somewhat related: For dot files, it would be nice if they were ignored by default unless I type /.. For example myproj/. would list all dot files in, e.g., my_myproj. The tricky part here would be to avoid searching hidden directories until needed

@lotabout
Copy link
Owner
lotabout commented Jul 2, 2016

@Stebalien fzf-rs will read an environment variable and invoke it to fetch the input:

export FZF_DEFAULT_COMMAND=(git ls-tree -r --name-only HEAD || ag -l -g "")

@lotabout
Copy link
Owner
lotabout commented Jul 2, 2016

For the dotfiles, currently fzf-rs is designed to be a general search utility, so it shouldn't and couldn't change the input source.

It is really handy to toggle showing hidden files by the input. If the input source provides all files(including hidden ones), we might hide them by default and show them when the query matches some form. Anyway I'll try to investigate that.

@Stebalien
Copy link
Author

Ah. I didn't realize fzf was a general purpose menu.

It is really handy to toggle showing hidden files by the input. If the input source provides all files(including hidden ones), we might hide them by default and show them when the query matches some form. Anyway I'll try to investigate that.

You could have a --hide-unless-match REGEX flag (poor name, sorry) that hides all strings matching REGEX unless the input string matches REGEX. For hidden files, one could use --hide-unless-match '\(^\.|/\.\)'.

@quodlibetor
Copy link

I'm not sure how you're walking files and directories right now, but the ignore crate from ripgrep could probably help implement this.

Running just sk now by default includes all the .git files as well as the duplicate directory tree created by IDEs, which is a little unfortunate.

@lotabout
Copy link
Owner

@quodlibetor Thank you very much for the information, good to know that!

The above information is a little old. By default, sk run find . to retrieve the file list. You can overwrite the command by setting the environment variable SKIM_DEFAULT_COMMAND. For example, you can utilize the git ls-tree and ag command by: SKIM_DEFAULT_COMMAND=(git ls-tree -r --name-only HEAD || ag -l -g "").

Since sk is a general purpose filter, "ignore" feature is better to be achieved outside sk. This issue remains open because we are talking about toggling filters dynamically.

Anyway, thank you for the ignore crate!

@quodlibetor
Copy link

Ah, cool, SKIM_DEFAULT_COMMAND='git ls-tree -r --name-only HEAD || rg --files' is exactly what I wanted. Your desire for separation of concerns is completely reasonable.

@nick-benoit14
Copy link

What is thought about adding a line like this to the vim plugin?

let $SKIM_DEFAULT_COMMAND = "git ls-tree -r --name-only HEAD || rg --files || find ."

That way the seperatation of concerns is still maintained, and the common use case for vim users is met out of the box?

lotabout added a commit that referenced this issue Oct 5, 2017
As described in #3, I do think a better default for SKIM_DEFAULT_COMMAND
is good for both new and old users.
@lotabout
Copy link
Owner
lotabout commented Oct 5, 2017

@nick-benoit14 Thanks for the suggestion!

By setting default command, user might met situation where a file is not committed and thus cannot be found by skim.

Not setting default command, user will find it OK for the first time and find it inconvenient for the rest of time(if they are using git).

To me, the default options are hard to choose. It is about the balancing the use cases. This time I agree it might be better to set the default command as you said.

@lotabout lotabout closed this as completed Oct 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants