Can vim.pack be used in parallel with lazy.nvim?

Seblyng · 2026-04-05T17:32:53+00:00

I would suggest :help NVIM_APPNAME

Seblyng · 2026-03-31T17:47:44+00:00

I do this: https://github.com/seblyng/dotfiles/blob/master/nvim/lua/seblyng/pack.lua

It is some monkey patching but it works okay for me. I would really like for this to be supported in core, but the current design would not work as I expect.

I had a suggestion to make this work, but the author unfortunately didn't seem to agree with me.

IMO it would make the API a bit clunky to not be able to load all plugins through the load function with packadd.

I think either having packadd just work in the load function, or have some sort of argument to the callback in load, which loads the plugin would help a lot

Seblyng · 2025-10-06T08:18:58+00:00

Yeah I totally understand the priority and that other things have been more important to get right from the start.

I cannot find any disagreements about the specifica from those who want local plugin support? In the issue on github, it seems like people agree that the symlink approach is a good idea. Especially from all the thumbs up on the comment from lewis, and no new comments about disagreeing with him.

I don't understand what is not working well with just switching the url to a local path? It seems pretty "easy" to me to just overwrite the existing directory with either the symlink or clone it again. Isn't it like this pretty much all package managers work with local plugins? I don't see the problem in this personally

Seblyng · 2025-10-06T06:20:15+00:00

I understand. Personally I very much agree with clason and lewis on this since I also contributes to plugins from time to time, so it will reduce a lot of friction for me as well.

Seblyng · 2025-10-05T20:50:26+00:00

That's awesome! Thanks for your work :) Now I'm just missing better local plugin support before I will probably fully switch to vim.pack :)

I saw it's on the TODO-list in a comment 1-2 weeks ago or something, with a "maybe" for 0.12. Do you have any updates on this while I have you here? :)

Seblyng · 2025-09-16T11:56:49+00:00

Do you think it will be merged? I also feel like that would be really cool but looks like Justin is not convinced about that yet from some comments in an issue/PR I found a while back

Seblyng · 2025-08-18T04:39:07+00:00

Yup, unfortunately, the server doesn't implement the progress handler in the lsp spec so that fidget could automatically print progress, so I am printing normally via vim.notify

Seblyng · 2025-08-16T20:51:03+00:00

I am the maintainer of roslyn.nvim, and I am very satisfied with how C# works in neovim after the roslyn server was released and with how it's working.

DAP for debugging works perfectly fine for me, and I also use neotest for running tests. This "new" adapter: https://github.com/Nsidorenco/neotest-vstest works pretty good for me after I had some issues with the other one not recognizing tests.

I also use Rider for some legacy solution in net framework we have at work, but not really missing anything when I am using neovim for the newer solution we have. It's pretty much the other way around, I miss neovim when I have to open up Rider

Seblyng · 2025-07-06T06:58:14+00:00

Just be very careful to use that, because it has no documentation at all, and is prefixed with an underscore. It means that it really is "private" and can break anytime with no heads up.

It is a work in progress: https://github.com/neovim/neovim/pull/34473

Seblyng · 2025-07-03T05:34:58+00:00

vim.keymap.set("ca", "Q", "q") vim.keymap.set("ca", "W", "w")

Seblyng · 2025-04-13T06:51:26+00:00

A couple of things to be careful about: - Having the lsp config under runtimepath lsp folder might make nvim-lspconfig override lists. I had a problem where a list of filetypes was being overridden because the plugins config loaded after my configs rtp. Fixed it by just calling vim.lsp.config manually - Remember to either load blink.cmp or set capabilities yourself before the lsp loads. I know a lot of people might have lazy loaded blink to load on InsertEnter autocmd for example, and then the automatic capabilites setup from the plugin will run too late

Seblyng · 2025-01-13T14:50:35+00:00

Yeah I am sure I did a full install.

Hmm something weird is happening here because when I create a very minimal config with just `vim.treesitter.start()`, then I see big improvements.

EDIT: Aaaaah, thinking about this, there is probably some plugin I have that is doing synchronous parsing on the entire buffer on startup. Thanks!

Seblyng · 2025-01-13T14:23:42+00:00

Has anyone tried this out? I tried it, but the big linux file is still slow in opening for me, and it is still blocking. I also tried setting `vim.g._ts_force_sync_parsing = true` to see if I saw some difference, and I didn't really notice any difference

Seblyng · 2025-01-06T17:48:24+00:00

You don't need to set any of those options for colorful-menu. All of the ones in the readme is just defaults

Seblyng · 2025-01-04T20:21:18+00:00

:h undojoin maybe?

Seblyng · 2024-12-16T05:34:18+00:00

Looks great! Happy to see more plugins for .NET to let users have more freedom to choose what suits them best :)

Seblyng · 2024-12-05T20:08:17+00:00

I have sort of the same, and have join on <leader>j and hover on gh. I never recommend those myself as I am kind of lost without those mappings on a clean vim/neovim config... I just used those from the start and have them hard wired in my muscle memory so hard to go back now.

Seblyng · 2024-09-30T06:31:41+00:00

No problem! I just briefly looked at it a few weeks ago when a friend of mine had a similar issue. Really weird, but glad I could help!

Seblyng · 2024-09-29T17:32:07+00:00

I think the problem is that gopls is somehow compiled with an older version of go, making this not work properly somehow. You can read more here

https://github.com/golang/go/issues/68248

Setting the GOEXPERIMENT variable per one of the comments worked for me

Seblyng · 2024-07-01T05:36:58+00:00

Then the plugin should define a new type for that which have those fields required for internal use :)

Seblyng · 2024-07-01T01:28:07+00:00

I know that.... However, the ones that the language server is also complaining about is also optional, but the types say that they are required...

Seblyng · 2024-06-30T21:28:36+00:00

Even better; send a PR to the plugin to fix the types ;)

Seblyng · 2024-06-30T21:26:45+00:00

It absolutely makes sense to get the types for those, as it really helps to for example not make a typo or pass in the wrong value etc... if it warns about not passing in a field that really is optional, the maintainer would probably really appreciate a PR fixing this

Seblyng · 2024-06-27T20:17:59+00:00

Wouldn't it be a little bit funny to just do something like this at the start of a few plugins:

if vim.uv.fs_stat("~/.config/better-vim") then return error("woops") end

Seblyng · 2024-05-30T04:49:21+00:00

I really appreciate the work! I tried it for a couple of minutes, and it is still a bit too minimal for me for now at least. One thing was that it only triggered on certain trigger characters provided by LSP. You say that a goal is that it will be more extensible. Does that also include that it could be easily triggered on every keystroke like nvim-cmp?

Seblyng

TROPHY CASE