lspsaga.nvim
lspsaga.nvim copied to clipboard
Adhoc buffer creation or option to restrict the number of buffers / entries when using lsp_finder
Is your feature request related to a problem? Please describe.
Working with code that has a lot of references can cause problems when using lsp_finder
in combination with other plugins. I guess mostly because a buffer is created for each entry.
Error executing vim.schedule lua callback: Vim(lua):E5108: Error executing lua ...k/packer/start/gitsigns.nvim/lua/gitsigns/subprocess.lua:71: Failed to spawn process: {
_state = {
pid = "EMFILE: too many open files",
stderr = <userdata 1>,
stderr_data = {},
stdout = <userdata 2>,
stdout_data = {}
},
args = { "--no-pager", "config", "user.name" },
command = "git"
}
Describe the solution you'd like
I don't know how difficult, slow and resource heavy it would be to create a buffer on the fly. If it is reasonable, the finder could create the buffer only when a reference is actually inspected instead of creating them all in advance.
Describe alternatives you've considered
If adhoc buffer creation is not feasible, maybe an option to restrict the number of buffers or entries in the finder could be added.
There is actually already an option for this: max_preview_lines
. Problem with this, it is applied after the buffers are created which will not prevent problems caused by too many buffers.
As an alternative to fetching the file contents with buffers, one could think of using file system operations instead. In my test it dit not performe worse but avoided buffer related auto commands and therefore did not trigger the previously mentioned exception.
Since it might still be undesirable to have 100 or 1000 of references to scroll through, an option to limit the number of entries in the lsp_finder window could be added.
The only problem I encountered was the loss of filetype detection and therefore syntax highlighting in the previews. A library like plenary can help with that but would add a maybe unwanted dependency.