Pre select first element during search

[ilan-schemoul]

Is your feature request related to a problem? Please describe.

Very often searching a file takes +10 seconds. However 99% the time the result I search for already appears as the first result very quickly. So I want to press to select it. However during a search nothing is pre-selected So doesn't work. I have to either wait 10/20 seconds for the search to be over. Or press then to select element at the bottom then to open it. It's a big big pain point for me.

Describe the solution you'd like

Select the first element during the search so I can just

Is it smart-open or telescope issue ?

Well I think it's telescope behaviour not to select anything during search. But it makes sense for all of their native finders as search is super quick (<1s) even on super large files. And also smart-open already knows what file I know (because of frencency) without scanning everything. So unlike other finders I would like to have a pre selection of first element during search

[xzbdmw]

You can have two keymaps one for cwd and one for all files, and former is very fast.

[ilan-schemoul]

Having two keymaps for similar things is always annoying because I always mix them up. Also the problem is not related to using only cwd or not but rather I have a huge repository I work with at work. This repository has a massive build folder when I compile. The root of the issue was this package is slow because it surprisingly has ignore_file set to false which is IMO a terrible idea. Especially as it wasn't customizable. https://github.com/danielfalk/smart-open.nvim/pull/80 So when you have a massive .build folder not ignored because ignore=false it's slow.

[danielfalk]

Yeah this is a telescope behavior as far as I can tell. It seems to wipe out the selection when more results are added to the picker. I don't know if there is a fix, but if someone can figure out a way to make this work, that would be great.

[danielfalk]

The root of the issue was this package is slow because it surprisingly has ignore_file set to false which is IMO a terrible idea. Especially as it wasn't customizable. #80 So when you have a massive .build folder not ignored because ignore=false it's slow.

Let's be civil here now.

Anyway, by default, ripgrep does respect .gitignore, unless I'm missing something. The only parameters that smart-open adds are, --files, --glob-case-insensitive, --line-buffered, --hidden, --ignore-file=<basedir>/.ff-ignore

So, as long as build is in .gitignore, then I would expect this ripgrep command to skip over that directory. If that's not happening, maybe there's a bug we can take a look at.

[ilan-schemoul]

Anyway, by default, ripgrep does respect .gitignore, unless I'm missing something

I don't think it does. Take a look at my PR. It sets no_ignore to false by default which is not the case currently (so currently it's doing the equivalent of no_ignore true so it doesn't follow the .git ignore).

Can you test with and without my PR and telling if I'm missing something

[xzbdmw]

both rg and this plugin indeed skip files in .gitignore by default

[yongli-abc]

Hi, I'm very new to neovim and telescope in general and I think I'm affected by this too, when I just start telescope from my user directory ~.

Does it mean telescope generally can't work from the user directory? Appreciate your guidance! 🙏

[xzbdmw]

There are a lot of files, you can cd to where your project is, then open nvim.