Summary
treesj can be lazy-loaded at the plugin-manager level, but language presets are still eagerly loaded once the plugin initializes.
Current behavior
lua/treesj/langs/init.lua iterates over every configured language and immediately runs:
require('treesj.langs.' .. lang)lua/treesj/settings.lua then requires treesj.langs during settings initialization and prepares all presets up front.
As a result, using lazy.nvim only defers loading the plugin itself. After the plugin is loaded, all language preset modules are required immediately, even if only one language is ever used in the session.
Expected behavior
Language presets should ideally be loaded on first use for the current Tree-sitter language, instead of requiring every lua/treesj/langs/*.lua file during startup.
Why this matters
This would make the plugin's internal loading behavior match the expectation set by plugin-manager lazy loading more closely, and reduce unnecessary module loading for unused languages.
Summary
treesjcan be lazy-loaded at the plugin-manager level, but language presets are still eagerly loaded once the plugin initializes.Current behavior
lua/treesj/langs/init.luaiterates over every configured language and immediately runs:lua/treesj/settings.luathen requirestreesj.langsduring settings initialization and prepares all presets up front.As a result, using
lazy.nvimonly defers loading the plugin itself. After the plugin is loaded, all language preset modules are required immediately, even if only one language is ever used in the session.Expected behavior
Language presets should ideally be loaded on first use for the current Tree-sitter language, instead of requiring every
lua/treesj/langs/*.luafile during startup.Why this matters
This would make the plugin's internal loading behavior match the expectation set by plugin-manager lazy loading more closely, and reduce unnecessary module loading for unused languages.