feat: support explicit lazy=false

[zoriya]

When specifying explicitly lazy = false but still keeping a lazy handler (keys for example), the lazy value is overriden to true.

My use case of specifying lazy = false is to configure plugins in the start directory of my packpath. For example:

return {
	{
		"oil.nvim",
		lazy = false,
		load = function() end,
		keys = {
			{ "-",    "<CMD>Oil<CR>", desc = "Open parent directory" },
			{ "<BS>", "<CMD>Oil<CR>", desc = "Open parent directory" },
		},
		opts = {
			skip_confirm_for_simple_edits = true,
			view_options = {
				show_hidden = true,
			},
			keymaps = {
				["<BS>"] = "actions.parent",
			},
		},
		after = function(plug)
			require("oil").setup(plug.opts)
		end
	}
}

[github-actions]

Review Checklist

Does this PR follow the Contribution Guidelines? Following is a partial checklist:

Proper conventional commit scoping:

• For example, fix(context): some bugfix

• Pull request title has the appropriate conventional commit prefix.

If applicable:

• Tested
  • Tests have been added.
  • Tested manually (Steps to reproduce in PR description).
• Updated documentation.

[HeitorAugustoLN]

I've been setting this:

{
  "nvim-treesitter",
  after = function()
      vim.opt.runtimepath:prepend(vim.fs.joinpath(vim.fn.stdpath("data"), "site"))
      require("nvim-treesitter.configs").setup({
          highlight = { additional_vim_regex_highlighting = { "ruby" }, enable = true },
          indent = { disable = { "ruby" }, enable = true },
          parser_install_dir = vim.fs.joinpath(vim.fn.stdpath("data"), "site"),
      })
  end,
  cmd = { "TSInstall", "TSUpdate", "TSUpdateSync" },
  event = { "BufNewFile", "BufReadPost", "BufWritePost", "DeferredUIEnter" },
  lazy = vim.fn.argc(-1) == 0,
}

to not lazy-load treesitter if I open a file directly, and it is working just fine.

And I don't think you should be setting a lazy handler if you are really don't want to lazy-load the plugin, it is just better to set the keymaps in the after function

[mrcjkb]

Hey 👋
Thanks for the PR. 🙏

As @HeitorAugustoLN mentioned, the keys table is not meant to be used as a DSL for defining keymaps.
If not used for lazy loading, it just adds overhead (to create the loading trigger keymaps).
I'd also recommend just to use vim.keymap.set.

I'm not sure how I feel about this suggested change in yet. Setting lazy = false and defining lazy-loading handlers is a conflict. But there may be a use case for wanting to override lazy loading under certain conditions. @HeitorAugustoLN in your example, I believe it's one of the events that triggers, not vim.fn.argc(-1) == 0?

@zoriya please also see the review checklist in the github-actions comment (if there is a good use case for this behaviour).
Regarding the commit prefix: This would be a feat, not a fix, as lazy = false was never intended.

[HeitorAugustoLN]

in your example, it's one of the events that triggers, not vim.fn.argc(-1) == 0?

just tested it, and yeah it is. i didn't thought so. But after testing out @zoriya modifications, looks like I gained a bit of startuptime

startuptime-lazy.log
startuptime-nolazy.log

Measured with:

nvim flake.nix --startuptime startuptime-lazy.log

with lazy = vim.fn.argc(-1) == 0

nvim flake.nix --startuptime startuptime-nolazy.log

with lazy = vim.fn.argc(-1) == 0 commented out

EDIT: Measured startuptime with the current latest lz.n and there really no difference with lazy = vim.fn.argc(-1) == 0 or not

[mrcjkb]

The difference is too small to be regarded as a benchmark, but thanks for the insight.
You presented a valid use case for wanting to explicitly set lazy = false.

[zoriya]

If you want I can update the PR to not setup lazy handlers when lazy = false. This would solve the overhead issue.

I'll update the PR with the checklist next week, I'm on vacation right now.

[mrcjkb]

If you want I can update the PR to not setup lazy handlers when lazy = false. This would solve the overhead issue.

No, that's fine. It would increase complexity and likely introduce unwanted behaviour.

[HeitorAugustoLN]

If you want I can update the PR to not setup lazy handlers when lazy = false. This would solve the overhead issue.

No, that's fine. It would increase complexity and likely introduce unwanted behaviour.

Yeah, agreed.

[zoriya]

I added a test & fixed the conventional commit

[mrcjkb]

I added a test & fixed the conventional commit

Thanks 🙏