Enhance lazy loading according to file type

[meijieru]

Currently, the filetype-based lazy loading slows up the start when directly opening a file.

Is it possible to delay the file type event until after the VeryLazy stage?

[abeldekat]

Hello @meijieru,

To my knowledge, the event itself cannot be delayed because its a neovim builtin. Decorating the event is possible: I have seen this in for example AstroNvim, defining the AstroFile user event as an aggregation of the BufReadPost, BufNewFile and BufWritePost events.

That said, I think the speed of any type of lazy loading is mostly affected by the configuration of the user. For example, interpreting the output you provided: For ft python, you don't need to load neotest when opening a python file. The loading of that plugin can be triggered by keys.

For inspiration, you could have a look at the following modules in LazyVim:

• lazyvim.plugins.extras.test.core
• lazyvim.plugins.extras.dap.core
• lazyvim.plugins.extras.lang.python

[meijieru]

Hello @abeldekat, I appreciate your guidance.

This approach is commendable.
However, there is a constraint for plugins such as nvim-dap-python, which ought to be exclusively loaded for Python, without requiring explicit keys or autocmds for loading.

Introducing an extra parameter like ft_late in the plugin specification could potentially address this.

[abeldekat]

Interesting!

Is that constraint a personal one? For example, having dap configured for multiple languages, nvim-dap-python can be present when debugging typescript. It only contains python info for dap, after all.

I would reason it's similar to configuring multiple lsp's with nvim-lspconfig. Given that config, the correct lsp kicks in based on the filetype events the nvim-lspconfig plugin has registered. When working on a typescript project, the pyright config is also not used.

I develop python myself, but I only use the ft keyword for the markdown-preview plugin.

[meijieru]

I've come across this situation while incorporating language-specific elements.
Although there are approaches to mitigate it, the ft keyword's current usability constraints remain.
Users might face this issue unknowingly.