telescope.nvim
telescope.nvim copied to clipboard
find_files results appear debounced on input on macOS
Description
When appending additional characters to the input of a find_files
prompt, the results appear to refresh with a delay of ~1 second on a repository with ~30k files. This is clear when typing the characters slowly.
When the characters are typed quickly, the results fresh instantly on the press of the next key. The behavior seems to be resemble throttling or debouncing of some kind.
I use the same neovim configuration across a person Linux desktop, personal Apple laptop, and work Apple laptop, and the behavior is only present on the two Apple laptops.
I'd love to assist further in the debugging of this, but have absolutely no idea where to get started. If you are able to provide some guidance, I'd love to help!.
Neovim version
NVIM v0.7.0-dev+792-gc46f7caad
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /Applications/Xcode_12.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -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 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/Users/runner/work/neovim/neovim/build/config -I/Users/runner/work/neovim/neovim/src -I/Users/runner/work/neovim/neovim/.deps/usr/include -I/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/include -I/Library/Frameworks/Mono.framework/Headers -I/Users/runner/work/neovim/neovim/build/src/nvim/auto -I/Users/runner/work/neovim/neovim/build/include
Compiled by [email protected]
Operating system and version
macOS 12.0.1
checkhealth telescope
telescope: require("telescope.health").check()
========================================================================
## Checking for required plugins
- OK: plenary installed.
- WARNING: nvim-treesitter not found.
## Checking external dependencies
- ERROR: rg: not found. `live-grep` finder will not function without [BurntSushi/ripgrep](https://github.com/ BurntSushi/ripgrep) installed.
- OK: fd: found fd 8.2.1
## ===== Installed extensions =====
## Telescope Extension: `fzf`
- INFO: No healthcheck provided
Steps to reproduce
- clone a large repository, e.g. nixos/nixpkgs
-
cd
into repository - launch
nvim
- activate telescope with
:Telescope find_files
- quickly type
tail
to establish a narrow result set - slowly type
s
,c
,a
,l
, ande
telescope SHA: 1d1da664eb6505c318d405eea3d633c451edc2d8 plenary SHA: a672e11c816d4a91ef01253ba1a2567d20e08e55
Expected behavior
Results are refreshed ~instantly after each additional key press, like they are on Linux.
Actual behavior
Results are refreshed with a ~1 second delay, or immediately on the press of an additional key.
Minimal config
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
require('packer').startup {
{
'wbthomason/packer.nvim',
{
'nvim-telescope/telescope.nvim',
requires = {
'nvim-lua/plenary.nvim',
{ 'nvim-telescope/telescope-fzf-native.nvim', run = 'make' },
},
},
-- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
},
config = {
package_root = package_root,
compile_path = install_path .. '/plugin/packer_compiled.lua',
display = { non_interactive = true },
},
}
end
_G.load_config = function()
require('telescope').setup()
require('telescope').load_extension('fzf')
-- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
print("Installing Telescope and dependencies.")
vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]
I'm experiencing similar behavior as well.
maybe this is a duplication of #1423 ? can you confirm that this diff fixes things? https://github.com/nvim-telescope/telescope.nvim/issues/1423#issuecomment-968070320
Can you also test with Telescope find_files previewer=false
I also am experiencing this problem. Diff in that comment doesn't appear to affect performance at all for me.
Turning off the previewer does improve performance somewhat, but it is still noticeably laggy in the same way (i.e. not refreshing immediately until the next key is pressed).
Like @lehmacdj I also tried the diff which didn't seem to increase performance. I was testing with Live Grep. Turning off the previewer did help though. I also noticed that opening a file can take a little longer then expected (sometimes >1 sec). #1423 does seem like the same thing though.
Diff in that comment doesn't appear to affect performance at all for me.
I can also confirm this.
One new observation (with both patched and unpatched) is that when updating the search term with fast keystrokes, the "intermediate" results do not appear to be correct. Explaining this with some example below.
When typing slowly in nixpkgs
and starting with tailscal
, I see these file counts:
> tailscal 185/29377
> tailscale 34/29377
> tailscaled 8/29377
When typing quickly, I see these file counts:
> tailscal 185/29377
> tailscale 185/29377 (no change after the "e" key press)
> tailscaled 29/29377 ("d" key press updates count to an incorrect immediate result)
> tailscaled 8/29377 (after the ~1 second delay, count updates to correct value)
Repeating the typing quickly example, different intermediate counts are generated.
Maybe this will be better when I'm able to finish the fps
branch that switches to refresh rate style for display, rather than always trying to update the display (which can lead to some hard to manage behavior).
Hi, there!
I'm having the same problem here where it only updates when I press any key (like arrow keys for example).
Is there any workaround?
@tjdevries, is the fps
branch thing you mention still a thing? I pulled that down to test, but it seems borked atm.