srstevenson / vim-picker Goto Github PK

Would it be reasonable to map Escape to close the file picker by default? I intuitively try to use it to quit the picker - maybe it might be a sensible default?

First off, great plugin, I really like the approach.

I'm wondering though if there's a reason why there aren't split commands for all the command types?

For example, there's PickerEdit, PickerSplit, PickerVsplit, and PickerTabedit, but no split options for PickerBuffer, and no vertical split options for PickerTag.

Anyway, thanks again!

How to use vimpickerwithripgrep` to search a file that contains a specified string

This does not work well

nmap <leader>a :call picker#File("rg --column --line-number --no-heading --color=never --smart-case ''", 'edit')<cr>

It would be awesome if it would work same as <Plug>(PickerEdit)

(neovim v0.3.4)

A simple init.vim to reproduce

call plug#begin('~/.local/share/nvim/plugged')
Plug 'srstevenson/vim-picker'
call plug#end()

call picker#Register('foo', 'file', 'edit', 'find foo/path -type f')

This produces the following errors on startup:

Error detected while processing /Users/nickrw/.local/share/nvim/plugged/vim-picker/autoload/picker.vim:
line  399:
E127: Cannot redefine function picker#Register: It is in use
Error detected while processing function picker#Register:
line   28:
E117: Unknown function: picker#IsString
E15: Invalid expression: !picker#IsString(a:shell_cmd)
Press ENTER or type command to continue

Other function calls seem to succeed. If I drop call picker#ListUserCommands() in init.vim instead of the Register call then that executes successfully on startup. I don't understand the various interactions between vim-plug and ftdetect - I think this is causing vim-picker's autoload to get sourced twice. I'm going to do more digging, but thought I'd check if anyone knows if I'm just doing something stupid!

I just switched from CtrlP which I used for years, but there's one feature I miss very much. Sometimes I accidentally choose the wrong result and would be cool when this happens to be able to open picker again and prepopulate it with what I typed last time (like when I hit <C-P> second time when CtrlP is open) instead of typing it all again.

Anyway, great plugin, thanks for it 👏

Steps to Reproduce with split

1. Open neovim,
2. Split the window the horizontally :split,
3. Move focus to upper window, if not already there, <C-w> k,
4. Open vim-picker :PickerEdit,
5. Close vim-picker <Esc>,
6. Observe focus is now in bottom window instead of top window.

Steps to Reproduce with vsplit

1. Open neovim,
2. Split the window vertically :vsplit
3. Move focus to right window, if not already there, <C-w> l,
4. Open vim-picker :PickerEdit
5. Close vim-picker <Esc>,
6. Observe focus is now in left window instead of right window.

When I find some spare time, I will identify a solution and submit a PR. I think I posed a similar issue to Shougo's unite/denite plugin and Shougo patched it within hours. I've no idea how to manage window focus in vimscript, so I plan to start educating myself with Shougo's patch.

Related to #37 and #39.

I think I belatedly found a side-effect with using close! instead of bdelete!. While the picker window still closes consistently, my buffer list is accumulating term:// entries.

PR to follow.

:ls
  1  h   "modules/upp/pages/receiving/js_include.php" line 189
  2  h-  "term://.//22604:git ls-files --cached --exclude-standard --others|fzy ...
  3  h-  "term://.//23334:git ls-files --cached --exclude-standard --others|fzy ...
  4  h-  "term://.//6121:git ls-files --cached --exclude-standard --others|fzy ...
  5  h   "modules/upp/ajax/receiving/receive_uuid.php" line 212
  6  h-  "term://.//11662:git ls-files --cached --exclude-standard --others|fzy ...
  7  h   "modules/phreebooks/functions/phreebooks.php" line 1407
  8  h-  "term://.//16183:echo "term://.//22604:git ls-files --cached ...
 19  h-  "term://.//30248:git ls-files --cached --exclude-standard --others|fzy ...
 22  h-  "term://.//6787:git ls-files --cached --exclude-standard --others|fzy ...
 23  a   "modules/inventory/classes/install.php" line 0
 24  h-  "term://.//28440:git ls-files --cached --exclude-standard --others|fzy ...
 28  h   "[No Name]"                    line 0
 29  h-  "term://.//20669:git ls-files --cached --exclude-standard --others|fzy ...
 30  h-  "term://.//20686:git ls-files --cached --exclude-standard --others|fzy ...
 31 #a   "modules/inventory/config.php" line 0
 32  h-  "term://.//8590:echo "modules/upp/pages/receiving/js_include.php...
 33  h-  "term://.//8783:echo "modules/upp/pages/receiving/js_include.php...
 34  h-  "term://.//9146:echo "modules/upp/pages/receiving/js_include.php...
 35  h-  "term://.//9371:git ls-files --cached --exclude-standard --others|fzy ...
 36  h-  "term://.//9598:echo "modules/upp/pages/receiving/js_include.php...
 37  h-  "term://.//9980:echo "modules/upp/pages/receiving/js_include.php...
 38  h-  "term://.//10630:echo "modules/upp/pages/receiving/js_include.php...

I'd like to use vim-picker in the same way as netrw command :e., which reuses the current window. Could you please add an option for this?

I'd like to register a user-defined command to find all files with the same base name with the current file (but possibly with different file extensions, and in different sub-directories), something like this:

call picker#Register('alternate', 'file', 'edit', 'find . -name <current-file-name>.*')

But I couldn't find a way to get the current file base name in the shell_command part.

Using git ls-files --others is not ideal since it does not include git submodules.

There should probably be an option to ignore the git check and just use fd ...

Thank you for writing this plugin.

Using command :PickerEdit [directory] frequently in one project. Is that possible to support working directory option base on '.project', '.git'.

Something like 'let g:picker_working_directory = '.git'

After running :PickerEdit and typing some keys I cannot use the arrow keys to select a match. As soon as I hit an arrow key the terminal closes and E21: Cannot make changes, 'modifiable' is off is printed.

If I run :term myself, then try to use fzy from with it I can select matches like I can when running fzy directly on the command line.

Also if I run the following manually I can also use the arrow keys:

:call term_start(["sh", "-c", "printf '%s\n' a b c | fzy"])

It would be nice is the files in the list were ordered by last access or last modification date, with most recent first. I don't seem to be able to get that information from git ls-files, so it might not be trivial to implement. An easier alternative would be to sort them by name with the option of reversing the order in configuration. My particular usecase for these is keeping working notes with the format YYYYMMDD-note-title.md and making it easier to see the most recent notes while allowing for fuzzy search on all of them.

This could be against the philosophy of fuzzy searching files instead of browsing through them, so feel free to close wontfix.

Recent versions of vim have a :terminal command which allows for a split in a terminal emulator. It would be nice if we could add this as an option for doing fuzzy finding, especially since it would permit using the fuzzy finder in gVim.

https://github.com/sharkdp/fd is the new kid on the block as an alternative to find(1), but obviously much faster (see benchmarks in README).

It would be nice to extend ListFilesCommand to check fo fd either between git and rg, or as first hit since it has some git filtering built in.

The autoloaded picker#Register() function isn't known to Vim at startup. This means a line such as

call picker#Register('notes', 'file', 'edit', 'find ~/notes -name "*.md"')

in your vimrc leads to the following error:

Error detected while processing /home/srstevenson/.vim/vimrc:
line   76:
E117: Unknown function: picker#Register
Press ENTER or type command to continue

This can be worked around until fixed by defining an autocommand on the VimEnter event:

autocmd VimEnter call picker#Register('notes', 'file', 'edit', 'find ~/notes -name "*.md"')

Hi and thanks for this plugin.

I recently tried it and my main issue with it is that :PickerBuffer is not initially sorted by last opened. Once I start typing, I don't care about the order anymore but it's useful to be able to go down 1 or 2 when you know with which files you're currently working with.

Buffers seem to be named their full absolute path (probably because they were opened with :PickerEdit. Could they be modified to be relative to the cwd?

It would be nice to have the ability to search through a most recent files list.

currently Picker uses bdelete after a selection is made, however this doesnt ensure that the :terminal window closes. Sometimes, the window will stay open at the bottom, and next time the picker command is invoked, it stacks below the previous picker window. Is there a way to use both bdelete and close so that the window closes and the buffer is deleted after selection?

#35 gave me this idea. I'm just spit-balling here, so this initial idea isn't fully thought out.

Most, if not all, commands follow the same pattern:

1. Specify a shell command
2. Specify a Pick* function (string | file)
3. Specify a vim command to invoke against the user's selection
4. Invoke picker without arguments.

These first three can be wrapped in a Dict as a single value, registered into a table in vim-picker with a unique name/ID, and invoked by ID.

A simple user-facing API might look like the following.

" vimrc
picker#register('recent-notes', {
  \ 'type': 'file',
  \ 'shell_command': 'find ...',
  \ 'vim_command': 'edit',
  \ })

nmap <unique> <leader>pn call picker#activate('recent-notes')<cr>

Why? It would allow users to customize vim-picker for their specific needs.

I'll work on a PR as I find time.

If I activate the PickerBuffer command using the mapping provided in README:

nmap <unique> <leader>pb <Plug>PickerBuffer

I got a lag about one second before the buffer list came up. If I call the command manually by typing :PickerBuffer and press enter, there is no lag. And if I define the mapping as following:

nmap <unique> <leader>pb :PickerBuffer<CR>

Then no lags.

All other commands work fine. Only PickerBuffer. Is it just me?

Would it be possible to support https://github.com/junegunn/fzf ? It's the only fzy alternative that supports windows natively that I've found so far

Would it be possible to fuzzy select locations from the location list or quickfix list within vim, and then jump to the selected location?

Other plugins - for example LanguageClient-neovim - populate these lists with various jump points, and it would be nice to be able to access these lists with a fuzzy searcher.

Using this plugin for a long time with no issues. Even if not maintained actively, addition of Lua API which is NeoVim thing has nothing to do with maintainence.

Is there a way to customize the background color of the Picker [command: edit, directory: ... ] line (green line in the screenshot)? I tried targeting StatusLine and StatusLineNC in my vim colorscheme file, but unfortunately that didn't seem to change it.

Alternatively is there a way to hide this line, perhaps a setting in vim-picker?

Thank you.

Hi, cool plugin. I tested it a bit and compared it to ctrlp with cpsm. What I found was that vim-picker doesn't take into account the current file. Do you think this might be a good idea? I think just using nothing as a base for searching is a worse guess than the current file. If you're in C code, for instance, you often want to take into account the current file as you might want to switch between .c and .h files, for instance.

EDIT: I did a little bit of researching and it seems that this should be really easy to do if you use fzy -q <current file>.

PickerBuffer works fine, but it shows the current opened buffer.

I wasn't really sure how to articulate this in the title. But basically, instead of having a command for every possible way to open a file (i.e. current buffer, split, vertical or tab). You'd have a keybinding that works on the selection list, similar to how ctrlp-p or fzf.vim works. So <C-v> to open the current selection in a vertical split, <C-s> for a horizontal split and <C-t> to open in a new tab. And just <CR> to open in the current buffer.

This way you only have to configure one keybind to open the search window, and then you can decide how you want to open the file you looked for, instead of before searching.

Does that make sense? :)