Conformation delay while searching through hidden files.

[txtyash]

Description

When I'm fuzzy finding through hidden files, even after having the desired file under the cursor, I can't press enter and open that file so I have to wait for a while until I can press return to open that file.

Neovim version

NVIM v0.5.1
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -DNDEBUG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim/src/neovim-0.5.1/build/config -I/build/neovim/src/neovim-0.5.1/src -I/usr/include -I/build/neovim/src/neovim-0.5.1/build/src/nvim/auto -I/build/neovim/src/neovim-0.5.1/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Operating system and version

Linux arch 5.14.15-zen1-1-zen #1 ZEN SMP PREEMPT Wed, 27 Oct 2021 23:38:11 +0000 x86_64 GNU/Linux

checkhealth telescope

health#telescope#check
========================================================================
## Checking for required plugins
  - OK: plenary installed.
  - OK: nvim-treesitter installed.

## Checking external dependencies
  - OK: rg: found ripgrep 13.0.0
  - WARNING: fd: not found. Install [sharkdp/fd](https://github.com/sharkdp/fd) for extended capabilities

## ===== Installed extensions =====

Steps to reproduce

map('n', 'fh', ':lua require"telescope.builtin".find_files({ hidden = true })', default_opts)

Open file search menu with the above mapping, then search for a hidden file with an obvious name, be a little verbose, then the desired file will appear at the bottom but you won't be able to open it for a short time period.

Expected behavior

I should be able to open the file with most matches without any delay just like when searching through not-hidden files.

Actual behavior

As you can see in the video, I'm unable to open mappings.lua even after telescope has found the right file. I have to wait for a little while.
Apologies. The video link is at the bottom, in another comment.

Minimal config

I'm sorry I didn't want to invest time in reproducing the error from scratch because it seemed like an overkill. IG the video is helpful enough.

[Shatur]

Can reproduce even with https://github.com/nvim-telescope/telescope-fzf-native.nvim

[txtyash]

I don't know if I did it correctly but here's what I did:

• Installed the plugin

• with this configuration:

require('telescope').setup {}
require('telescope').load_extension('fzf')

• It did result in a delay again but it was surprisingly shorter. And I'd say this time it was very much acceptable.

Now, I'm not sure if there's caching of frequently opened files or something but to be fair I had to try it with the same file. So opening mappings.lua with the plugin you suggested was pretty quick as compared to my issue.

I'd also tried unloading the fzf-native plugin and opening the file. Again, the results were the same. Telescope was more responsive with fzf-native.

[Shatur]

It did result in a delay again but it was surprisingly shorter

Yes, It reduces delay, but it still exits.
But there was no such problem before. The issue exists since timeouts for previews.

[txtyash]

I'm stupid enough to do it but I roughly did a countdown.

• without fzf-native - 4secs
• with fzf-native - 2secs

[Conni2461]

So this is not an issue if previewer=false?

[Shatur]

So this is not an issue if previewer=false?

No, still can be reproduced even with disabled previewer.

[Conni2461]

Does it get better if you apply this patch:

diff --git a/lua/telescope/pickers.lua b/lua/telescope/pickers.lua
index 212c236..b061994 100644
--- a/lua/telescope/pickers.lua
+++ b/lua/telescope/pickers.lua
@@ -353,7 +353,7 @@ function Picker:find()
   -- want to scroll through more than 10,000 items.
   --
   -- This just lets us stop doing stuff after tons of  things.
-  self.max_results = 1000
+  self.max_results = popup_opts.results.height
 
   vim.api.nvim_buf_set_lines(results_bufnr, 0, self.max_results, false, utils.repeated_table(self.max_results, ""))
 

[Shatur]

Does it get better if you apply this patch:

Yes, much better!

[Conni2461]

So its the scrolling. A faster entry_manager (better datastructure and/or compiled code) will probably be necessary.
See #1270 for a proof of concept

[Shatur]

So its the scrolling. A faster entry_manager (better datastructure and/or compiled code) will probably be necessary.

Got it. Can we have self.max_results = popup_opts.results.height as a temporary fix?

[Conni2461]

we kinda cant because then we will need to reopen #42 .

We could make a temporary optional config value. Something that can be set now but will be removed as soon as we figured out the performance issues.

[Shatur]

we kinda cant because then we will need to reopen #42 .

That's bad. Hope that the performance issues will be resolved soon.

[l-kershaw]

Could we maybe use the async v2 stuff that was implemented in #987?
My (admittedly limited 😅) understanding of how that works, is that it cancels "jobs" on each update to the prompt value, so that the new search results can be populated more quickly. Are we able to leverage the same functionality to cancel the job when an item is selected?
@Conni2461 @tjdevries is this something that is feasible?

[Shatur]

BTW, How is helix-editor's file picker so crazzzy fast? It doesn't even take an eye-blink to search through and open files.

This is because helix is in Rust (compiled language), and Telescope is written in Lua (scripting language).

[Conni2461]

What i great comment i love it. Sadly it was deleted. But i wish you the best with helix.

So to everyone else who is running still running neovim. We are working towards making it better. The easiest way is to run my proof of conecpt branch: https://github.com/Conni2461/telescope.nvim/tree/break/c_rewrite to adds c to telescope. Its not feature complete with the current version but its 5 times faster. Checkout branch and run make in telescope.nvim root dir. Should just work.

The second thing that is more likely to hit is #1491 which would allow us to use different data structures in the future. It basically changes the "rendering" of telescope. Here is a now leaked video of it running presented by tj:
https://user-images.githubusercontent.com/15233006/144120670-f58880d1-099e-4142-a7a3-2232545e3102.mp4

Everyone who wants more information about it: you should check out this vod: https://www.twitch.tv/videos/1209914667

The last 1 - 2 hours we talked about datastructures (tj talked, i wrote)

[Shatur]

The easiest way is to run my proof of conecpt branch: https://github.com/Conni2461/telescope.nvim/tree/break/c_rewrite to adds c to telescope.

Awesome, thank you for working on it!

[Conni2461]

Its the same thing i mentioned here #1423 (comment). But it still works and it feels faster. So it could be a temporary solution for everyone who needs a solution right now and i just keep that branch rebased.

But we can't just ship it because it would break lua5.1 (because of missing cffi module) and its probably not what we want in the long run.

[tjdevries]

CONNI LEAKING MY PRIVATE MESSAGES?!?!?!

[Shatur]

Going into normal mode and pressing G after the desired file has appeared brings focus onto the best match asap.

Same here. Looks like it waits for all results before focus the first one. @Conni2461 could we just select the first item right after it becomes available? I could solve the issue because we usually don't care about other 1000+ items :D