-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn into module and lazy-load #35
Comments
Yeah, for a while I've been thinking about that maybe it's time to explode the single source file. On the other hand, in Lightspeed's case this might not be the most pressing thing to do. The plugin is still pretty lightweight, there's not much logic running when requiring, except for defining a bunch of highlight groups and checking/defining mappings; it's almost in the same order of magnitude than lazy-loaded plugins (currently it adds 20ms on my super-slow laptop, where the absolute bare-bone ones are around 1-3ms). And I can hardly imagine any editing session without using it, it is an even more basic tool than surround or targets. Moreover, for any search executed, we will need pretty much the whole codebase anyway (we're processing everything ahead of time, this is the very concept), thus there's not much sense in modularizing it too much yet - for this reason, at least. One more thing: motion plugins are kinda special in this regard, since for those even the slightest noticeable pause can be super-annoying when the loading is deferred to the actual invocation (looking at you, targets.vim). That said, as I mentioned above, I'm thinking about this, and will probably do the big refactor sometime in the near future. (E.g. the highlight section is almost certain to get its own module.) |
Yeah, I understand that completely. For me, it's about 1.3ms out of 50ms -- not at all terrible, but the largest single time for a plugin without configuration (beating even I was certainly not asking to re-engineer for absolutely minimal startup time -- I agree that this makes little sense in this case if(!) there are trade-offs. |
I agree with clason, it would be nice to see proper lazy-loading capabilities. As a workaround I put the following in my packer.nvim config: use {
'ggandor/lightspeed.nvim',
keys = {
'<Plug>Lightspeed_s',
'<Plug>Lightspeed_S',
'<Plug>Lightspeed_x',
'<Plug>Lightspeed_X',
'<Plug>Lightspeed_f',
'<Plug>Lightspeed_F',
'<Plug>Lightspeed_t',
'<Plug>Lightspeed_T',
},
setup = function()
local default_keymaps = {
{ 'n', 's', '<Plug>Lightspeed_s' },
{ 'n', 'S', '<Plug>Lightspeed_S' },
{ 'x', 's', '<Plug>Lightspeed_s' },
{ 'x', 'S', '<Plug>Lightspeed_S' },
{ 'o', 'z', '<Plug>Lightspeed_s' },
{ 'o', 'Z', '<Plug>Lightspeed_S' },
{ 'o', 'x', '<Plug>Lightspeed_x' },
{ 'o', 'X', '<Plug>Lightspeed_X' },
{ 'n', 'f', '<Plug>Lightspeed_f' },
{ 'n', 'F', '<Plug>Lightspeed_F' },
{ 'x', 'f', '<Plug>Lightspeed_f' },
{ 'x', 'F', '<Plug>Lightspeed_F' },
{ 'o', 'f', '<Plug>Lightspeed_f' },
{ 'o', 'F', '<Plug>Lightspeed_F' },
{ 'n', 't', '<Plug>Lightspeed_t' },
{ 'n', 'T', '<Plug>Lightspeed_T' },
{ 'x', 't', '<Plug>Lightspeed_t' },
{ 'x', 'T', '<Plug>Lightspeed_T' },
{ 'o', 't', '<Plug>Lightspeed_t' },
{ 'o', 'T', '<Plug>Lightspeed_T' },
}
for _, m in ipairs(default_keymaps) do
vim.api.nvim_set_keymap(m[1], m[2], m[3], { silent = true })
end
end,
} This makes it so that lightspeed is loaded only on-demand, when one of the mappings is actually invoked. |
@disrupted nice, thanks for sharing! |
All of the mappings for Lightspeed use |
I appreciate that the current design is much easier to maintain, but it would be nice to have
lightspeed
do proper on-demand loading (similarly to how old vimscript plugins did the heavy lifting inautoload
functions that are not sourced unconditionally at startup).(Basically, you want to move as much as possible into modules that are
require
d only on executing the mappings.)The text was updated successfully, but these errors were encountered: