Turn into module and lazy-load

[clason]

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 in autoload functions that are not sourced unconditionally at startup).

(Basically, you want to move as much as possible into modules that are required only on executing the mappings.)

[ggandor]

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.)

[clason]

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 vim-fugitive), so I just thought there might be some low-hanging fruit somewhere.

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.

[disrupted]

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.

[ggandor]

@disrupted nice, thanks for sharing!

[milisims]

All of the mappings for Lightspeed use require'lightspeed', so if those are simply exported to a plugin/lightspeed.lua (or .vim) and the definitions could remain in lua/lightspeed.lua, I don't think anything else would need to change. Also, neovim will load plugin/*.lua files now, so the plugin/lightspeed.vim could be dropped.