Closed Twiggeh closed 1 year ago
There is currently no option to disable indent blankline based on file size. But are you sure it is caused by indent blankline? The plugin is build in a way that it only looks at, and updates, the current viewport. The file size should not matter. I also tested it with a clean install, and everything seems to work just fine.
I disabled all my plugins to test who was / were the culprits, and started enabling them one by one. Maybe it is an interaction with a different plugin, but indent-blankline
was definitely one of the ones that caused slowdowns (LSP & Treesitter's plugins were the other culprits).
I will check again with only indent-blankline
and then see whether an interaction with a different plugin was the cause & add a reproducible example.
The perfomance hit happend when opening / editing a large ts file.
You can see in btop whenever the nvim goes to 100% cpu usage is when I try to execute paste / open the file with indentline enabled.
I am sorry I don't know what the keystroke recording software is, so that was the only way I could think of showing when I execute something.
You can see after disabling indentline the file opens much faster and pasting is not affected.
Can you share your indent-blankline config?
local status_ok, indent_blankline = pcall(require, "indent_blankline")
if not status_ok then
return
end
vim.g.indent_blankline_buftype_exclude = { "terminal", "nofile" }
vim.g.indent_blankline_filetype_exclude = {
"help",
"startify",
"dashboard",
"packer",
"neogitstatus",
"NvimTree",
"Trouble",
}
vim.g.indentLine_enabled = 1
-- vim.g.indent_blankline_char = "│"
vim.g.indent_blankline_char = "▏"
-- vim.g.indent_blankline_char = "▎"
vim.g.indent_blankline_show_trailing_blankline_indent = false
vim.g.indent_blankline_show_first_indent_level = true
vim.g.indent_blankline_use_treesitter = true
vim.g.indent_blankline_show_current_context = true
vim.g.indent_blankline_context_patterns = {
"class",
"return",
"function",
"method",
"^if",
"^while",
"jsx_element",
"^for",
"^object",
"^table",
"block",
"arguments",
"if_statement",
"else_clause",
"jsx_element",
"jsx_self_closing_element",
"try_statement",
"catch_clause",
"import_statement",
"operation_type",
}
-- HACK: work-around for https://github.com/lukas-reineke/indent-blankline.nvim/issues/59
vim.wo.colorcolumn = "99999"
-- vim.cmd [[highlight IndentBlanklineIndent1 guifg=#E06C75 gui=nocombine]]
-- vim.cmd [[highlight IndentBlanklineIndent2 guifg=#E5C07B gui=nocombine]]
-- vim.cmd [[highlight IndentBlanklineIndent3 guifg=#98C379 gui=nocombine]]
-- vim.cmd [[highlight IndentBlanklineIndent4 guifg=#56B6C2 gui=nocombine]]
-- vim.cmd [[highlight IndentBlanklineIndent5 guifg=#61AFEF gui=nocombine]]
-- vim.cmd [[highlight IndentBlanklineIndent6 guifg=#C678DD gui=nocombine]]
-- vim.opt.list = true
-- vim.opt.listchars:append "space:⋅"
-- vim.opt.listchars:append "space:"
-- vim.opt.listchars:append "eol:↴"
indent_blankline.setup({
-- show_end_of_line = true,
-- space_char_blankline = " ",
show_current_context = true,
-- show_current_context_start = true,
-- char_highlight_list = {
-- "IndentBlanklineIndent1",
-- "IndentBlanklineIndent2",
-- "IndentBlanklineIndent3",
-- },
})
stolen from lunarvim
I still cannot reproduce the issue. If you make a full config that reproduces this, I can investigate more.
As a temporary solution, you can add an autocmd to your config like this that will disable indent line if the file is too big
vim.api.nvim_create_autocmd("BufEnter", {
group = vim.api.nvim_create_augroup("IndentBlanklineBigFile", {}),
pattern = "*",
callback = function()
if vim.api.nvim_buf_line_count(0) > 1000 then
require("indent_blankline.commands").disable()
end
end,
})
A bit unrelated, but that lunarvim config is not very good... You can clean this up a lot, this should be better.
local status_ok, indent_blankline = pcall(require, "indent_blankline")
if not status_ok then
return
end
indent_blankline.setup({
char = "▏",
show_trailing_blankline_indent = false,
show_current_context = true,
filetype_exclude = {
"help",
"startify",
"dashboard",
"packer",
"neogitstatus",
"NvimTree",
"Trouble",
}
})
The autocommand fixes the editor-lag :blush:, but unfortunately the "opening" of the file is still super slow. I couldn't find a better autocmd, to fix that I would probably need to put the same call on nvim tree and telescope when opening new buffers ?
Thanks for showing a better config :blush:
My config: https://github.com/Twiggeh/nvim-cfg
I don't use nvim-tree or telescope, so I can't answer that. It is really difficult to fix this, without first knowing what causes the lag. I still can't reproduce any issue. And sorry, your config is too big for me to set it all up and test with that. I'd really need a minimal, reproducible example to look into this more.
I'd really need a minimal, reproducible example to look into this more.
This only happens with treesitter
vim.g.indent_blankline_use_treesitter = true
vim.g.indent_blankline_show_current_context = true
Example file: 100MB sql file compressed using 7zip and disguised as txt
File takes 20s to open (make sure to have a parser for sql installed :TSInstall sql
)
autocommand maybe solve this
autocmd("BufEnter", {
group = myAutoGroup,
pattern = "*",
callback = function()
local max_filesize = 100 * 1024 -- 100 KB
local ok, stats = pcall(loop.fs_stat, api.nvim_buf_get_name(api.nvim_get_current_buf()))
if ok and stats and stats.size < max_filesize then
-- require("plugin-config.todo-comments")
require("indent_blankline.commands").enable()
end
end,
})
-- TODO: disable indentline before loading file
autocmd("BufReadPre", {
group = myAutoGroup,
pattern = "*",
callback = function()
-- vim.api.nvim_cmd(vim.api.nvim_parse_cmd("IndentBlanklineDisable", {}), {}) o
-- if vim.api.nvim_buf_line_count(0) > 1000 then
require("indent_blankline.commands").disable()
-- end
end,
})
I can also verify like @LostNeophyte that the startup time of Neovim is considerably slowed down when using this plugin together with Treesitter and setting show_current_context = true
.
Setting show_current_context = false
negates the problem. I tried conditionally enabling the property with a function, but interestingly enough, even a function in its most basic form of
show_current_context = function()
return false
end,
replicates the slowdown problem. I suspect there is some unintentional loop occurring when setting show_current_context
to a function.
I suspect there is some unintentional loop occurring when setting show_current_context to a function.
No, show_current_context
is a boolean only. If you set it to a function, lua will just treat it as true
I agree it would be nice to dynamically turn the plugin (or context) on and off. But this is quite a big change. I need to find time for this.
I somehow discovered that this plugin slows down *.dart
files as well, even simple short files. At first I thought it was the akinsho/flutter-tools.nvim plugin or even treesitter, but adding dart files to excluded filetypes removed lags completely.
vim.g.indent_blankline_filetype_exclude = {
"help",
-- exclude dart files
'dart',
"startify",
"dashboard",
"packer",
"neogitstatus",
"NvimTree",
"Trouble",
}
@lordvidex I tested it with a dart file (1000+ lines) and I didn't notice any lags. Btw, I had dart parser enabled in TS. So probably it's not caused by this plugin directly.
This is now supported in version 3, see :help ibl.hooks.register()
With the newer configuration method, how does one disable any interaction with tree-sitter? I am running into signification performance issues with a 350ish line file. I've isolated this plugin so that toggling whether it is disabled significantly increases or decreases performance. I tried:
require("ibl").setup {
enabled = true,
scope = { enabled = false }
}
but the performance issues remain. They are fixed by setting the top-level enabled to false (which of course sadly disables the plugin! The plugin is very useful, I would like to use it).
Sorry I am quite new to nvim so this might be a stupid question, but I noticed with super large files (200k lines) having this plugin enabled murders the performance of nvim.
Is there a way to disable it programmatically when the files are too large ?
(e.g. is possible in tree-sitter)