Skip to content
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

bug: some simple plugins seem not to be successfully lazy-loaded via event = "…" #190

Closed
3 tasks done
fooness opened this issue Dec 27, 2022 · 6 comments
Closed
3 tasks done
Labels
bug Something isn't working

Comments

@fooness
Copy link

fooness commented Dec 27, 2022

Did you check docs and existing issues?

  • I have read all the lazy docs
  • I have searched the existing issues of lazy
  • I have searched the exsiting issues of the plugin I have a problem with

Neovim version (nvim -v)

0.8.1

Operating system/version

macOS 13.1

Describe the bug

There’s already an open discussion for this issue: #187

I’m trying to lazily load (among others) rstacruz/vim-closer and tpope/vim-endwise via event = "…"; when doing so, the plugins are not working as intended, even though :Lazy shows them as loaded. I tried event = "VeryLazy", event = "VimEnter", and event = "InsertEnter".

Steps To Reproduce

  1. save minimal config attached below (default minimal config plus the two bespoke plugins)
  2. nvim -u repro.lua
  3. enter insert mode
  4. type function() {
  5. press enter key

Expected Behavior

The plugins should be inserting the closing } as well as the ending end:

function() {
}
end

… but instead, nothing happens.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
  { "rstacruz/vim-closer", event = "VeryLazy" }, -- plugin does *not* work as intended
  { "tpope/vim-endwise", event = "VeryLazy" }, -- plugin does *not* work as intended
  -- { "rstacruz/vim-closer" }, -- plugin does work as intended
  -- { "tpope/vim-endwise" }, -- plugin does work as intended
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@fooness fooness added the bug Something isn't working label Dec 27, 2022
@folke
Copy link
Owner

folke commented Dec 27, 2022

Works for me. Can't repro:

image

@folke folke closed this as completed Dec 27, 2022
@folke
Copy link
Owner

folke commented Dec 27, 2022

https://github.com/rstacruz/vim-closer/blob/master/plugin/closer.vim sets up filetype autocmds, which would not trigger if you opened a file from the cmdline. so either add a vim.cmd("do FileType") to its config, or don't lazy-load it since it's not doing pretty much only that

@fooness
Copy link
Author

fooness commented Dec 27, 2022

https://github.com/rstacruz/vim-closer/blob/master/plugin/closer.vim sets up filetype autocmds, which would not trigger if you opened a file from the cmdline.

Huh, that’s interesting. I can confirm that when opening a file via e.g. netrw, the plugins do work.

so either add a vim.cmd("do FileType") to its config, or don't lazy-load it since it's not doing pretty much only that

Is there any more documentations and/or examples on how to do this in general in some elegant way? Maybe it’s totally unnecessary to load such plugins lazily … I simply though that those plugins could be loaded later, as they are not necessary early on; maybe I was wrong on this.

@folke
Copy link
Owner

folke commented Dec 27, 2022

Those plugins are simply not built to be lazy-loaded it seems. Most modern plugins would check existing buffers when loading, but the ones here don't.

@folke
Copy link
Owner

folke commented Dec 27, 2022

You could try loading them with event="FileType". That would probably work. That or BufReadPre

@fooness
Copy link
Author

fooness commented Dec 27, 2022

You could try loading them with event="FileType". That would probably work. That or BufReadPre

Indeed, event="FileType" does work. That looks like a satisfying approach to me.

Thank you for taking the time to read through and look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants