Don't load DAP when it's not needed about astronvim HOT 5 OPEN

Thmhis is how it used to be out of the box but left users very confused when the ensure_installed table that automatically installed debuggers didn't do anything. For now we don't have a real path forward for this without greatly decreasing the out of box experience. For this reason we made it load on opening a file and made it so the user has to opt into more aggressive lazy loading like you have

from astronvim.

Another option is to use the mason-tool-installer.nvim plugin for installing mason packages which is super great (this is what I use on my personal configuration) which also will move the lazy loading to being more aggressive for dap as the automatic installation is handled separately. It's available in AstroCommunity:

https://github.com/AstroNvim/astrocommunity/blob/main/lua%2Fastrocommunity%2Futility%2Fmason-tool-installer-nvim%2Finit.lua

I think I am leaning towards making this the default again. It was previously, but had a relatively slow startup time but I feel like that has improved.

I also think the way the spec is made in AstroCommunity could be considered a non-breaking change 🤔

from astronvim.

Ah actually, looking at this it looks like there is a part of the mason-tool-installer that does load the plugins for the mappings.... One sec that actually should probably be removed

Ah it is necessary to not be breaking because the installation mason plugins are required for some packages mappings

from astronvim.

@RayJameson So I got a new feature PR merged into mason-tool-installer to improve this (WhoIsSethDaniel/mason-tool-installer.nvim#49)

I will plan on making this a default in AstroNvim v5 with the integrations disabled by default.

In the meantime I would recommend the following adding the following to your community.lua file:

  { import = "astrocommunity.utility.mason-tool-installer" },

In AstroCommunity we are now disabling the other mason plugin integrations by default to default improve lazy loading which tends to be a main reason for using this plugin anyway. Then users can opt into the integrations that they way.

from astronvim.

Nice! I'll stick to my workaround for now, but eventually, I'll move to the community plugin

from astronvim.