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

Testers #1

Open
tjdevries opened this issue Nov 23, 2020 · 7 comments
Open

Testers #1

tjdevries opened this issue Nov 23, 2020 · 7 comments

Comments

@tjdevries
Copy link
Member

Hey @tami5 maybe you can use this in your projects to do live grep? I was just messing around with the idea.

cc @Conni2461 @clason

@kkharji
Copy link
Member

kkharji commented Nov 23, 2020

😮 I'll check it out tom, hopefully we can get the post we need. So this experimental? then it will be used in the main branch whether as fzf-writer or fzy-native writer?

@gfanto
Copy link

gfanto commented Nov 23, 2020

I was hoping so much about this extension because i love Telescope, but i cannot use it in large projects with this is super fast, Thank You!
Unfortunately i don't know much lua, but if you need help testing it, i will be super happy giving my help.
Thanks again!

@kkharji
Copy link
Member

kkharji commented Nov 24, 2020

  • Doesn't work with cwd option to a path, it just show current working dir
    • side effect to setting cwd: Doesn't resolve and open file correctly for some reason, opens /home/tamibam/.local/share/nvim/site/pack/compe/init.lua instead of /home/tamibam/.local/share/nvim/site/pack/packer/opt/nvim-compe/lua/compe/init.lua

@kkharji
Copy link
Member

kkharji commented Nov 24, 2020

Duplication of listed files.

@lynndylanhurley
Copy link

@tjdevries grep is still unusably slow for me. I have a large codebase, and the input hangs for 10-20 seconds between keypresses.

This was my previous configuration using fzf, which felt instant:

function! RipgrepFzf(query, fullscreen)
  let command_fmt = 'rg --column --line-number --no-heading --color=always --smart-case %s || true'
  let initial_command = printf(command_fmt, shellescape(a:query))
  let reload_command = printf(command_fmt, '{q}')
  let spec = {'options': ['--phony', '--query', a:query, '--bind', 'change:reload:'.reload_command]}
  call fzf#vim#grep(initial_command, 1, fzf#vim#with_preview(spec), a:fullscreen)
endfunction

command! -nargs=* -bang Rg call RipgrepFzf(<q-args>, <bang>0)

nnoremap <Leader>/ :Rg<CR>

This is my current configuration with telescope:

Plug 'nvim-lua/plenary.nvim'
Plug 'romgrk/fzy-lua-native', { 'do': 'make' }
Plug 'nvim-telescope/telescope.nvim'
Plug 'nvim-telescope/telescope-fzf-writer.nvim'
Plug 'nvim-telescope/telescope-fzy-native.nvim'

lua <<EOF
require('telescope').setup {
    extensions = {
        fzf_writer = {
            -- Disabled by default.
            -- Will probably slow down some aspects of the sorter, but can make color highlights.
            -- I will work on this more later.
            use_highlighter = false,
        }
    }
}
require('telescope').load_extension('fzy_native')
EOF

nnoremap <leader>/ :lua require('telescope').extensions.fzf_writer.staged_grep()<CR>

@lynndylanhurley
Copy link

@tjdevries I also left an issue about this in the main telescope repo (nvim-telescope/telescope.nvim#392).

It really seems like this is an issue with the design of telescope. The processing of the results seems like it needs to happen in some kind of background thread so the UI doesn't hang.

@tjdevries
Copy link
Member Author

@tjdevries I also left an issue about this in the main telescope repo (nvim-telescope/telescope.nvim#392).

It really seems like this is an issue with the design of telescope. The processing of the results seems like it needs to happen in some kind of background thread so the UI doesn't hang.

Yes :) but adding background threads makes it much much harder and for some cases I think it's possible it will make it slower (processing all the text, transforming into something that can be sent to thread, etc.). I have plans to work on it, but it is large architectural work and (tbh) I think we're the first Lua plugin to need threads for CPU bound work (many need it for IO bound work, but that's what vim.loop.spawn does for you already... so it's much easier for those kinds of tasks).

I do hope to make it happen some day :) thanks for the suggestion!

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