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

[FEATURES REQUEST]: take into account of wildignore option and filter FuzzyFiles results with readable. #38

Open
ubaldot opened this issue Aug 23, 2024 · 7 comments · May be fixed by #42

Comments

@ubaldot
Copy link
Contributor

ubaldot commented Aug 23, 2024

I was thinking to a couple of improvements for this tool:

  1. Take into account of the value of wildignore in the search patterns. Many user may have defined some patterns in their wildignore, that can include common patterns like for example .git, etc.
    option and finding results including what they want to exclude could be a bit annoying.
  2. :FuzzyFiles may show non-readable files. If that is the case, would that be possible to exclude them from the list?
@Donaldttt
Copy link
Owner

We have a PR working on a similar feature right now. It will be merge soon after testing.

@ubaldot
Copy link
Contributor Author

ubaldot commented Aug 24, 2024

Ok great! I added a note in the PR itself to take into account of 'wildignore'.

Unrelated: what about adding a :FuzzyDir command? That command shall display all the directories starting from pwd the callback after user selection from the popup menu would just... change directory. This would come very handy because when I need to change dir I never remember if foo/ is in ~/foo/, in ~/Documents/foo/ in ~/some/other/weird/location/foo/ and so on.

Unrelated 2: I know that you can list all the files from pwd in a dire with :e **/*<tab> and all the directories with :cd **/*/<tab>. This takes into account the value of wildignore. Could this facts be exploited to improve the search engine of the plugin?

@ubaldot
Copy link
Contributor Author

ubaldot commented Aug 24, 2024

Regarding Unrelated 2 this is possible (and it is blazingly fast).
There is a function called getcompletion(), and you can use it in many ways.
Few examples:

All the files:
:echo getcompletion('**/*', 'file')->filter('v:val != "\/$"')

All the dirs:
:echo getcompletion('**/*', 'dir')

All the coloschemes:
:echo getcompletion('', 'color')

... and much more.

Note that you can directly filter without creating a list first and then filter it, for example:

:echo getcompletion('**/*myfile', 'file')->filter('v:val != "\/$"')

returns the list of files that contains the string myfile that you can directly slam in the popup menu.
You can also choose if the search shall be fuzzy or based on regex, depending on what you put into wildoption option.

A possible way could be that when the popup is visible you set wildoption=fuzzy, call getcompletion({user_input}, {type}) at every keystroke, so the list becomes more and more refined, and then reset wildoption to its previous value once the user hit Enter.
Or, if you don't want fuzzy search, just call getcompletion() at every keystroke, with the first arguments containing what is written in the search box filled by the user.

This could simplify FuzzySeach() function perhaps? And you can re-use the same structure with whatever you want to search (colorscheme, files, directories, ...).

I am just giving some insights because I think this is a very nice plugin. :)

@Donaldttt
Copy link
Owner

Regarding Unrelated 2 this is possible (and it is blazingly fast).
There is a function called getcompletion(), and you can use it in many ways.
Few examples:

All the files:
:echo getcompletion('**/*', 'file')->filter('v:val != "\/$"')

All the dirs:
:echo getcompletion('**/*', 'dir')

All the coloschemes:
:echo getcompletion('', 'color')

... and much more.

Note that you can directly filter without creating a list first and then filter it, for example:

:echo getcompletion('**/*myfile', 'file')->filter('v:val != "\/$"')

returns the list of files that contains the string myfile that you can directly slam in the popup menu.
You can also choose if the search shall be fuzzy or based on regex, depending on what you put into wildoption option.

A possible way could be that when the popup is visible you set wildoption=fuzzy, call getcompletion({user_input}, {type}) at every keystroke, so the list becomes more and more refined, and then reset wildoption to its previous value once the user hit Enter.
Or, if you don't want fuzzy search, just call getcompletion() at every keystroke, with the first arguments containing what is written in the search box filled by the user.

This could simplify FuzzySeach() function perhaps? And you can re-use the same structure with whatever you want to search (colorscheme, files, directories, ...).

I am just giving some insights because I think this is a very nice plugin. :)

Thank you! I will definitely look into these functions!

@ubaldot
Copy link
Contributor Author

ubaldot commented Aug 25, 2024

Just found that using :echo getcompletion('**/*', 'file') may take some time if you are in ~

Anyway, another function worth mentioning is systemlist() to get the output of external programs such as grep or findtsr in a very convenient way - you could perhaps avoid using jobs and related channels and callbacks. But I found other interesting functions that could be useful. I will come later.

@Donaldttt
Copy link
Owner

Just found that using :echo getcompletion('**/*', 'file') may take some time if you are in ~

Anyway, another function worth mentioning is systemlist() to get the output of external programs such as grep or findtsr in a very convenient way - you could perhaps avoid using jobs and related channels and callbacks. But I found other interesting functions that could be useful. I will come later.

Yeah, the reason I use job is for its async feature. Any blocking call such as systemlist() may cause vim to not be responsive if you are in a large directory.

@ubaldot
Copy link
Contributor Author

ubaldot commented Aug 26, 2024

That makes sense :)

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

Successfully merging a pull request may close this issue.

2 participants