Comments (39)
add event = "VimEnter" then i should load as soon nvim is started
from lazyvim.
Yes, there's currently an issue with overwriting an existing lazy keymap. Will fix this!
from lazyvim.
Fixed in folke/lazy.nvim@74bc61a
from lazyvim.
Thanks! The telescope search is using "Find Files" now as expected, but unfortunately it's still slow. Is there some kind of lazy loading happening for telescope that can be disabled? I reverted back to my old configuration without lazy and saw telescope results show up immediately even on first search, but with lazy it takes considerably longer, between 0.5-1 seconds or so.
I also already have lazy = false
set in my telescope plugin spec.
from lazyvim.
event = "VimEnter"
Thanks, I tried this, but it made no difference, the results in telescope are still loading slowly.
from lazyvim.
Weird, it's very fast for me... Did you try adding fzf-native?
from lazyvim.
This is my telescope spec in it's entirety;
return {
"nvim-telescope/telescope.nvim",
dependencies = {
{ "nvim-telescope/telescope-fzf-native.nvim", build = "make" },
},
lazy = false,
event = "VimEnter",
keys = {
{
"<leader>df",
function()
require("telescope.builtin").find_files({
prompt_title = "Dotfiles",
cwd = "~/dotfiles/",
hidden = "true",
})
end,
desc = "Find Dotfiles",
},
{
"<leader>gb",
function()
local actions = require("telescope.actions")
require("telescope.builtin").git_branches({
attach_mappings = function(prompt_bufnr, map)
map("i", "<c-d>", actions.git_delete_branch)
map("n", "<c-d>", actions.git_delete_branch)
return true
end,
})
end,
desc = "Find Git Branches",
},
{
"<leader>ff",
function()
require("telescope.builtin").find_files({ hidden = true })
end,
desc = "Find Files",
},
{
"<leader>fg",
function()
require("telescope.builtin").live_grep({ hidden = false })
end,
desc = "Find Grep",
},
{
"<leader>fb",
function()
require("telescope.builtin").buffers({})
end,
desc = "Find Buffers",
},
{
"<leader>gs",
function()
require("telescope.builtin").git_status({})
end,
desc = "Find Git Status",
},
{
"<leader>gl",
function()
require("telescope.builtin").git_commits({})
end,
desc = "Find Git Log",
},
{
"<leader>f/",
function()
require("telescope.builtin").current_buffer_fuzzy_find({})
end,
desc = "Find In File",
},
},
config = function()
local telescope = require("telescope")
telescope.setup({
defaults = {
vimgrep_arguments = {
"rg",
"--color=never",
"--column",
"--hidden",
"--line-number",
"--no-heading",
"--smart-case",
"--with-filename",
},
prompt_prefix = " ❯ ",
selection_caret = "❯ ",
entry_prefix = " ",
initial_mode = "insert",
selection_strategy = "reset",
sorting_strategy = "descending",
layout_strategy = "horizontal",
layout_config = {
horizontal = {
mirror = false,
},
vertical = {
mirror = false,
},
prompt_position = "bottom",
width = 0.8,
preview_cutoff = 120,
},
mappings = {
i = {
["<esc>"] = function(...)
return require("telescope.actions").close(...)
end,
},
},
path_display = {
"absolute",
},
file_sorter = require("telescope.sorters").get_fzy_sorter,
file_ignore_patterns = { "^.git/" },
generic_sorter = require("telescope.sorters").get_generic_fuzzy_sorter,
winblend = 0,
border = {},
borderchars = { "─", "│", "─", "│", "╭", "╮", "╯", "╰" },
color_devicons = true,
use_less = true,
set_env = { ["COLORTERM"] = "truecolor" }, -- default = nil,
file_previewer = require("telescope.previewers").vim_buffer_cat.new,
grep_previewer = require("telescope.previewers").vim_buffer_vimgrep.new,
qflist_previewer = require("telescope.previewers").vim_buffer_qflist.new,
},
})
telescope.load_extension("fzf")
end,
}
from lazyvim.
i guess it is not related to lazyloading. if it would be too "lazy", the delay would be the drawing of the telescope window, not the results.
from lazyvim.
I agree, it's very strange. My old telescope config is here, the major difference being the use of fzy_native
instead of fzf
, I'll try switching over to fzy_native on lazy as well, but it seems really weird that fzf would be slower.
from lazyvim.
@altosys you added fzf native, but you don't use it, since you do file_sorter = require("telescope.sorters").get_fzy_sorter
So that's why it's slow. Removing that line might help
from lazyvim.
@altosys you added fzf native, but you don't use it, since you do
file_sorter = require("telescope.sorters").get_fzy_sorter
So that's why it's slow. Removing that line might help
I think that might have been it, but now when I start nvim I get this message every time:
# Plugin Updates
- **lazy.nvim**
- **LazyVim**
Press ENTER or type command to continue
How can I disable this message? Results will only appear in telescope after I press enter here, even if I manage to open the telescope prompt before the message comes up.
If I wait for the message after starting nvim and press enter, then it seems that telescope is indeed as fast as it should be.
from lazyvim.
Did you disable nvim-notify?
from lazyvim.
you can disable those messages in lazy config. Check the lazy docs
from lazyvim.
Yeah I did disable nvim-notify, it was bugging me a bit too much with messages I didn't really have a need for. I disabled the update messages by setting notify = false
for checker
, but now I'm scratching my head because telescope is still not displaying files quickly. And just for reference, the number of files that it should list where I'm testing is only 85, so not a lot at all.
from lazyvim.
that message can't have anthing to do with telescope performance anyway.
IT's that sorter as I said. In your code you were not using fzf native.
from lazyvim.
Even in my home directory with 115000 files, Telescope is instant
from lazyvim.
that message can't have anthing to do with telescope performance anyway. IT's that sorter as I said. In your code you were not using fzf native.
Maybe I was unclear above, I've already commented out the sorter but the telescope delay is still there. Here's the current spec: https://hastebin.com/fapijujewu.lua
from lazyvim.
Just used your config on my home directory (including hidden it has 1.130.000 files.
Still opens instantly.
Edit: sorting does take a while there obivoulsy.
Doing it on the neovim souce code, sorting is also instatntly (1340 files)
from lazyvim.
There is most definitely something different between my lazy config and how it behaves with my legacy setup. I just compared it again and there is a 1 second delay with telescope on lazy which is not there with my old config. Could it be that something else is blocking telescope, another plugin or something?
I have my lazy setup here, and my legacy config is here, if there is any clue to be had as to what is happening.
I just now tried to remove all other plugin specs from my plugins folder, leaving only telescope. After cleaning out all other plugins the delay is still there. I can see that lualine appears at the same time as the telescope results, could it be possible that lualine is somehow affecting this?
from lazyvim.
The links you posted don't work for me. They're not public probably?
from lazyvim.
The links you posted don't work for me. They're not public probably?
Oh shit, sorry! I thought that repo was public already, it should be sorted now though.
from lazyvim.
The only difference seems to be zfy
, so maybe see if that fixes it for you?
Also if you see it is slow, can you say exactly what you mean?
- open Neovim
- wait till everything is loaded
- confirm with
:Lazy
that telescope is loaded and ready - run the telescope command you want to test from the cmdline:
Telescope find_files
After that, what is slow for you?
It takes a second before the Telescope window opens?
The window opens immediately, but the first results take a seconf to load?
The results open instantly, but sorting takes a second?
Also, check :Lazy profile
to see if something is taking a long time to load. Maybe Telescope is just not loaded yet when you try to run it with the keymap?
from lazyvim.
I did a couple of screen recordings trying to show the issue; in both clips what I'm doing is
1. open nvim
2. immediately press <leader>>ff for telescope
3. wait for telescope to open and populate the prompt
4. navigate the files
In this first clip I'm using my legacy packer setup, and you can see that telescope populates the prompt with files instantly, as would be expected.
In this other clip I have my lazy configuration in place, and its clear how it for some reason takes a huge amount of time before telescope populates the same list of files.
Here's the imgur post to be able to play them side by side as well.
@folke when you say to "wait till everything is loaded", what do you mean? Isn't telescope supposed to load up immediately since I set it to lazy = false
?
If I open neovim and just sit and wait for a few seconds and then open telescope, then at that point it does populate the prompt instantly, so there is some kind of startup going on which is preventing telescope from doing its thing right away.
I checked the profiling in lazy, with the output below, lazy measures the startup time as 73ms, I'm not sure what's included in that though, lualine for instance doesn't show up within 1 second, which also seems to coincide with telescope being ready.
Startuptime: 73.03ms
Based on the actual CPU time of the Neovim process till UIEnter.
This is more accurate than `nvim --startuptime`.
LazyStart 16.97ms
LazyDone 62.08ms (+45.11ms)
UIEnter 73.03ms (+10.95ms)
Profile
You can press <C-s> to change sorting between chronological order & time taken.
Press <C-f> to filter profiling entries that took more time than a given threshold
● lazy.nvim 14.97ms
➜ module 5.95ms
➜ config 0.17ms
➜ spec 5.9ms
★ lazyvim.plugins.coding 0.12ms
★ lazyvim.plugins.colorscheme 0.03ms
★ lazyvim.plugins.core 0.24ms
★ lazyvim.plugins.editor 0.44ms
★ lazyvim.plugins 0.94ms
★ lazyvim.plugins.lsp 0.07ms
★ lazyvim.plugins.treesitter 0.05ms
★ lazyvim.plugins.ui 0.1ms
★ lazyvim.plugins.util 0.07ms
★ plugins.autopairs 0.03ms
★ plugins.cmp 0.05ms
★ plugins.colorscheme 0.04ms
★ plugins.comment 0.02ms
★ plugins.core 0.43ms
★ plugins.gitblame 0.05ms
★ plugins.gitsigns 0.03ms
★ plugins.go 0.13ms
★ plugins.hop 0.1ms
★ plugins.indent_blankline 0.53ms
★ plugins.lualine 0.14ms
★ plugins.markdown 0.06ms
★ plugins.misc 0.39ms
★ plugins.telescope 0.07ms
★ plugins.transparent 0.05ms
★ plugins.tree 0.07ms
★ plugins.treesitter 0.16ms
★ plugins.trouble 0.04ms
★ plugins.vim-cutlass 0.03ms
★ plugins.vim-go 0.13ms
➜ state 0.29ms
➜ install 0.07ms
➜ handlers 2.58ms
● startup 35.48ms
➜ runtime/filetype.lua 0.19ms
➜ init 0.07ms
★ init dressing.nvim 0.03ms
★ init nvim-navic 0.01ms
★ init neo-tree.nvim 0.01ms
★ init nvim-treesitter-textobjects 0ms
➜ start 34.39ms
★ start LazyVim 4.53ms
‒ tokyonight.nvim 2.83ms
★ start kanagawa.nvim 2.2ms
★ start lualine.nvim 7ms
‒ nvim-web-devicons 0.33ms
● nvim-web-devicons/plugin/nvim-web-devicons.vim 0.09ms
★ start indent-blankline.nvim 0.87ms
‒ indent-blankline.nvim/plugin/indent_blankline.vim 0.66ms
★ start telescope.nvim 14.03ms
‒ telescope-fzf-native.nvim 0.2ms
‒ telescope.nvim/plugin/telescope.lua 0.22ms
‒ plenary.nvim 0.19ms
● plenary.nvim/plugin/plenary.vim 0.06ms
‒ nvim-treesitter 4.79ms
● nvim-treesitter-textobjects 0.24ms
● nvim-treesitter/plugin/nvim-treesitter.lua 1.78ms
★ start Comment.nvim 0.86ms
‒ Comment.nvim/plugin/Comment.lua 0.62ms
★ start gitsigns.nvim 4.82ms
‒ trouble.nvim 2.22ms
● trouble.nvim/plugin/trouble.vim 0.11ms
➜ rtp plugins 0.69ms
★ runtime/plugin/health.vim 0.06ms
★ runtime/plugin/man.lua 0.07ms
★ runtime/plugin/rplugin.vim 0.2ms
★ runtime/plugin/shada.vim 0.11ms
★ runtime/plugin/spellfile.vim 0.07ms
➜ after 0.09ms
● VimEnter 4.75ms
➜ alpha-nvim 0.78ms
➜ alpha_start 3.93ms
● VeryLazy 25.36ms
➜ mini.comment 0.7ms
➜ mini.pairs 1.9ms
➜ vim-repeat 0.08ms
➜ which-key.nvim 22.58ms
★ which-key.nvim/plugin/which-key.vim 0.06ms
● InsertEnter 38.65ms
➜ nvim-cmp 38.4ms
★ cmp-buffer 3.7ms
‒ after/plugin/cmp_buffer.lua 3.22ms
★ cmp-cmdline 1.08ms
‒ after/plugin/cmp_cmdline.lua 0.9ms
★ cmp-nvim-lsp 0.96ms
‒ after/plugin/cmp_nvim_lsp.lua 0.71ms
★ cmp-nvim-lsp-signature-help 0.96ms
‒ after/plugin/cmp_nvim_lsp_signature_help.lua 0.75ms
★ cmp-path 0.92ms
‒ after/plugin/cmp_path.lua 0.75ms
★ cmp_luasnip 0.87ms
‒ after/plugin/cmp_luasnip.lua 0.69ms
★ nvim-cmp/plugin/cmp.lua 1.13ms
★ lspkind.nvim 0.11ms
★ LuaSnip 22ms
‒ friendly-snippets 20.18ms
‒ LuaSnip/plugin/luasnip.vim 0.37ms
‒ LuaSnip/ftdetect/snippets.vim 0.06ms
➜ ___cmp___ 0.02ms
➜ cmp_nvim_lsp 0.16ms
from lazyvim.
I think I know what the problem is!
You are using version="*"
, but telescope's last release is very old, so try setting version=false
for telescope, then update and see if that fixes it
from lazyvim.
To really compare it, best to comment the line config.defaults.version
.
from lazyvim.
This line https://gitlab.com/altosys/dotfiles/-/blob/lazy/links/.config/nvim/lua/config/lazy.lua#L21
from lazyvim.
Can't be that, you are using LAzyVim and I already set version=false
for Telescope
from lazyvim.
When you are testing, you do try it in the same directory right?
from lazyvim.
Yes, I always test in the same folder to keep it consistent. I tried commenting out version=*
but it didn't make any difference.
from lazyvim.
What if you comment the line below? Then LazyVim will load, but without any of your extra plugins.
https://gitlab.com/altosys/dotfiles/-/blob/lazy/links/.config/nvim/lua/config/lazy.lua#L14
If that works as expected, then change that line to only additionally load telescope, so make it imvport = "plugins.telescope"
and see if that still works ok.
from lazyvim.
I commented that line out, but telescope is still slow. I would say it's a bit faster, but still far from instant as it should be.
from lazyvim.
What does nvim --startuptime foo.txt
show?
Something must be loading after lazy and before you run telescope.
Your screencast is definitely not normal
from lazyvim.
Did you already check :checkhealth lazy
?
from lazyvim.
I checked it again now, this is what it says:
lazy: require("lazy.health").check()
========================================================================
## lazy.nvim
- OK: no existing packages found by other package managers
- OK: packer_compiled.lua not found
from lazyvim.
nvim --startuptime foo.txt
doesn't show me anything but starting up nvim as normal to the dashboard, are you referring to using this plugin https://github.com/dstein64/vim-startuptime or something other?
from lazyvim.
Super odd all of this. You'll have to figure it out on your own. It's hard for me to debug when I don't have anything reproducible.
It's indeed also weird that it takes a second before lualine shows. But since you don't see anything in either startuptime or lazy profile, it must be something not during startup. But what could that be then?
Now that I think about it, it could be the checker! Try setting config.checker.enabled = false
in your lazy config.
That triggers right after startup to check for updates. And during that time, it's normal that things would be slower for a second or so.
If that's the issue then either you have to live with it (only once per startup), you can disable it, or you can set the checker concurrency to a low number, so it will have a smaller footprint.
from lazyvim.
I tried disabling the checker, that didn't make a noticeable difference. What I did find is that if I just went and removed all my nvim stuff so that I only kept my keymaps and vanilla lazyvim without any plugin specs etc, then telescope works as it should, blazingly fast.
So what I'll do is I'll nuke everything, then bring things back piece by piece while checking along the way if and when the telescope issue appears. I'll report back any findings of course and perhaps we'll get to the bottom of this.
Also I can't begin to thank you enough for all your efforts in helping me, this has truly been a headscratcher. I really appreciate all the support since I really want to be able to use lazy, I think you really knocked it out of the park with this one :)
from lazyvim.
Sounds good and do let me know if you find anything :)
Thanks!
from lazyvim.
So finally coming back to this after being insanely busy for the past two weeks.
I couldn't find anything causing the startup delay, I think it must've been some leftover file in my .local/share/nvim
from packer. I've been using this config for two weeks now and it is very fast and very satisfying :)
from lazyvim.
Related Issues (20)
- bug: Compilation errors from treesitter HOT 1
- ansible-lint command failed HOT 4
- bug: change keymap from <leader>bd to <leader>c is slow HOT 5
- bug: Visual Bug when on top of the file HOT 7
- Add toggle for nvim-cmp HOT 11
- Error executing vim.schedule lua callback HOT 12
- stack corruption detected (-fstack-protector)
- feature: Install LazyVIm in a isolated environment. No Internet. HOT 2
- feature: add johmsalas/text-case.nvim plugin HOT 1
- bug: Unhelpful error when trying to install a plugging that does not exist HOT 4
- bug: LspInfo command gives E464: ambiguous use of user-defined command HOT 2
- Inlay hints broken in recent dev version of neovim.
- bug: Unable to mix Deno and non-Deno files in the same workspace HOT 3
- feature: Toggle conform formatting HOT 5
- feature: use blame.nvim instead of telescope blame HOT 1
- bug: "Fix clangd offset encoding" doesn't work, still "utf-8" in C/C++ buffer HOT 23
- bug: confirming completion triggers rust-analyzer diag HOT 4
- Bufferline not anymore working in LazyVim HOT 13
- feature: configurable lualine path trimming HOT 2
- feature: When a prompt is triggered while typing, the prompt panel appears transparent. Is it possible to add an option to prevent it from becoming transparent?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lazyvim.