mini.bracketed: regression with 20+ seconds startup time with on Windows 10

matu3ba commented 2 months ago

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)

bracketed

Description

20+ seconds of startup time with mini.bracketed being setup.

Sidenode: It might be useful, if you provide a issue template like stevearc does in overseer for a minimal.lua https://github.com/stevearc/overseer.nvim/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml&title=bug%3A+

Neovim version

NVIM v0.10.0-dev-3080+gefb44e0ca

Steps to reproduce

Content of minimal.lua with something like

    local plugins = {
    'echasnovski/mini.bracketed',
    version = false,
    config = function()
      require('mini.bracketed').setup {
        comment = { suffix = 'v' }, -- verbose comment
        -- treesitter = { options = { add_to_jumplist = true } },
      }
    end,
  },

nvim -nu minimal.lua

Expected behavior

negligible startup time

Actual behavior

very significant startup time

echasnovski commented 2 months ago

Thanks for the issue!

Unfortunately, I can not reproduce. I am using Linux, but I don't see anything platform depended done inside require('mini.bracketed').setup(). My startup entry is 017.970 000.259 000.259: require('mini.bracketed') with overall time 040.047 000.002: --- NVIM STARTED ---.

I would like to ask you for a couple of ways to narrow down the problem:

Try running nvim --startuptime nvim.log and later inspect 'nvim.log' file to ensure that this is 'mini.bracketed' fault.
Update to latest Nigthly (the latest build is NVIM v0.10.0-dev-3100+gd3fa88b70).
If the problem persists, try reproduce on latest stable 0.9.5.

matu3ba commented 2 months ago

Observations so far on Windows:

the problem of the slowdown is not strictly deterministic, sometimes startup is reasonably fast (for Windows)
outside the strict determinism I can reproduce the problem reliably with my dotfiles
the problem does not reproduce with this minimal example (with or without oil.nvim or here not included aerial.nvim makes no difference) and neither by adding the other plugins executing autocommands found via :verbose au BufEnter like oil or aerial on BufEnter:
```
--nvim -u repro.lua
-- 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", { "stevearc/dressing.nvim", config = true }, { "echasnovski/mini.bracketed", config = function() require('mini.bracketed').setup {} // comment = { suffix = 'v' }, -- verbose comment end, }, { 'stevearc/oil.nvim', config = function() require('oil').setup { view_options = { show_hidden = true } } end, }, } -- add any other plugins here require("lazy").setup(plugins, { root = root .. "/plugins", })

vim.cmd.colorscheme("tokyonight") -- add anything else here



Any more ideas how track this down?

echasnovski commented 2 months ago

Any more ideas how track this down?

Only bisecting the config, I'd say.

Closing as this currently doesn't look like an issue with 'mini.bracketed' (no slowdown when only it is loaded). If you'll have new finding, please let me know here.

echasnovski / mini.nvim