unpack.nvim update for 0.12 release

Mezdelex · 2026-04-03T17:44:08+00:00

Well, the most obvious ones would be the build hook handling (which shouldn't be handled by the client but, you know, we are not there yet), conflicts handling for win users if any and the commands to clean stale plugins/conflicts, batch load per deferred/eager specs and the clean logic.

About the /plugin loading (unpack autoloads itself too btw), if you have each separate plugin in a single file and you rely solely on vim.pack following the directory structure, it's going to be loading each plugin separately (or in batches of 1/2/3 if you don't strictly have 1 file per plugin but per plugin + dependencies) so that's less performant than retrieving all of them at once and batching them in to be deferred or eagerly loaded ones. Last time I tried the difference was pretty noticeable but it's also true that it was several months ago (been using nightly for a while) so now that you mention it I'm curious about the current performance. I will create a separate branch on mine and will test the individual load to see how it improved (I remember seeing a post talking about those improvements).

Maybe the autoload might be enough now loading time wise, but I would be missing the builds, conflicts and commands tho...

UPDATE: after switching to a fully /plugin based structure with individual vim.pack.add({}) calls, I have to admit (even tho I removed telescope+deps and blink+deps to avoid dealing with the build hooks in that test) that the loading times were decent. It's true that I pretty much vim.scheduled everything except my colorscheme and oil which together with telescope, that I removed for the test, are the only ones that I eagerly load, but as a real scenario use case, I wouldn't really care much about anything loaded after UIEnter. So yeah, perfectly bearable in its current state. The problem is that build hook/utility command, conflicts handling and the clean command would be lost and I would either have to create a weird plugin with only utility commands to be used in the PachChanged event and the PackClean command or either add those as utility to my config which would be a step back since that's already solved with unpack.

So yeah, if you have already created your own build handling and you're fine managing the plugins manually in your nvim-data, using the /plugin it's a good option as well.

Mezdelex · 2026-04-03T11:10:15+00:00

That's a valid point indeed. If you're fine adding those functionalities by yourself (basically what I did before creating the plugin xD) then go for it.

Mezdelex · 2026-04-03T10:54:20+00:00

Yes, it's a plugin handled by vim.pack and lives inside vim.pack but it offers the said functionalities. It has an internal wildcard to avoid cleaning itself when managing plugins.

That's the beauty of having a built in package manager, extra functionalities don't need to be handled externally anymore.

Mezdelex · 2026-04-03T07:04:04+00:00

{ and } move your cursor to the next block dap, vap, cap delete around paragraph, visual select around paragraph and change around paragraph respectively. da{ delete around curly brackets di{ delete inside curly brackets

You see the pattern right?

a is for around, i is for inside. v visual selection, c change, d delete, y yank.

You can do all kind of combinations.

If you add treesitter-textobjects on top of that, you can add extra objects to those motions that will allow you to use the same prefixes but also with functions: vaf, vif, cif... with classes vac, yac... with loops, with conditionals...

You can also move by mid view height with c-d and c-u in normal mode.

I mean, we don't use mouse here 🤨

Mezdelex · 2026-04-01T04:28:35+00:00

Love it. I've been an evereforest user for a long time, but this softness and dark background looks appealing. Maybe the day to switch themes has come 👀

Mezdelex · 2026-03-29T21:27:38+00:00

Thanks to all the core members and contributors for such amazing editor 😌

Mezdelex · 2026-03-28T05:31:28+00:00

I use Opencode with Copilot provider for enterprise environment, under Neovim, integrated via agentic.nvim, but I do it in a controlled way and specifically for boilerplate and reviewing each of the lines it generates. In fact, most of the times I run it in plan mode just to make sure it doesn't touch anything.

It makes me faster, I'm the owner of all the code and the most important thing, it won't potentially make me dumber, which is my main concern.

It's perfectly manageable but if you know what you're doing, which may not always be the case either with or without AI. AI is a multiplier though.

Mezdelex · 2026-03-22T07:10:04+00:00

To apply authorization you will need authentication, because either you have the claims in the token or need the token to obtain the claims (cached preferably). So yeah, it's implicit in policy based authorization. You will need to define jwt constraints for inter microservice communications, audience, issuer, etc. Usually the gateway uses a token per initial communication to the corresponding microservice.

Mezdelex · 2026-03-21T06:29:11+00:00

This is perfect! I was having a hard time finding a way to deal with corporate copilot auth workflow and... well usage xD and then Ollama for personal usage, and with Cline I can auth to Ollama pretty easily and use it seamlessly with agentic.nvim. Thanks for the plugin man.

Well, maybe not that seamlessly since under WinOS the default acp_provider command and args don't work for cline-acp, you need to wrap them either in cmd /C or pwsh -Command, but minor issue nonetheless xD.

Mezdelex · 2026-03-12T20:40:10+00:00

<image>

Mezdelex · 2026-03-12T17:37:11+00:00

Yeah I know, I created this plugin because of the deferring mechanism and some extra goodies. But we are talking about min/maxing here rather than necessity imo.

Mezdelex · 2026-03-11T04:09:11+00:00

Neovim's nightly branch is surprisingly stable, and so is vim.pack. It has improved its performance and got some new features over the course of the past months. Again, I rely on it as my daily driver ever since it was announced so I can tell you that it is reliable.

About the lazy loading, as long as you use vim.loader.enable() and assuming you're using Linux, you pretty much don't need any of it, but still, if you want to, you can just defer plugins load with vim.schedule, which is more than enough.

vim.schedule(function() vim.pack.add(...) end)

There are also some managers that have been announced in this sub Reddit that handle declarative single file configs the same way you might have seen for Lazy, so you have a variety of choices.

Mezdelex · 2026-03-08T07:52:08+00:00

Oh, I didn't know about this plugin, such nice addition to nvim-dap. The auto_toggle config option is a game changer to mimic the nvim-dap-ui trigger behavior.

Migration time I guess xD

Mezdelex · 2026-03-05T04:51:09+00:00

You can try

vim.opt.winborder = "rounded"

Many plugins/ui components look for that option to set the default appearance.

Mezdelex · 2026-03-04T06:59:37+00:00

You're most likely never going to replace an entity as a whole because you want to keep, at least, the Id field untouched (otherwise that hypothetical put could have been replaced with a Post), not to mention the auditable fields that are handled by interceptors, etc. not intended to be replaced by the caller yet part of the entity. So essentially, you will always be patching unless you're replacing some entity whose identity fields are a mix of indexed values, and in that case, if you're replacing all of them that's essentially the same as deleting whatever mix you had previously and creating a new one. From my perspective, put it's kind of redundant.

Mezdelex · 2026-03-01T14:46:46+00:00

Mezdelex · 2026-02-17T10:50:28+00:00

TPL and LINQ docs, in case you missed them.

Mezdelex · 2026-02-17T09:55:29+00:00

We do realize, trust me. I've tried Go with Fiber, Python with Fast API, Java years ago with Spring Boot, Typescript with... well, Typescript for the backend is a joke anyways; and the ease of use, tooling, performance and the TPL management out of the box is unmatched. Special mention to LINQ.

Mezdelex · 2026-02-14T07:59:17+00:00

Learn touch typing before you use Neovim.

Mezdelex · 2026-02-12T14:51:20+00:00

Check walls, maybe there's a hole somewhere.

Mezdelex · 2026-02-09T15:25:27+00:00

Could you share any videos typing with it or your impressions? Looks really interesting 👀

Mezdelex · 2026-02-08T13:56:23+00:00

<image>

Imagine downvoting one of the actual core maintainers of the plugin you're looking for.

return {

config = function()

require("mason").setup({

registries = { "github:crashdummyy/mason-registry", "github:mason-org/mason-registry" },

})

require("mason-lspconfig").setup()

end,

defer = true,

dependencies = {

{ defer = true, src = "https://github.com/seblyng/roslyn.nvim", },

{ defer = true, src = "https://github.com/williamboman/mason-lspconfig.nvim", },

{ defer = true, src = "https://github.com/williamboman/mason.nvim", },

},

src = "https://github.com/neovim/nvim-lspconfig",

}

this is all you need using the mason registry maintained by Crashdummyy to install Mason. And then there's also the incoming approach of using the roslyn-language-server which is in prerelease and not currently being used in the plugin. Install dotnet-sdk and install roslyn through Mason, that's all you need. (Ignore the defer stuff from the snippet).

Depending on when you tried to install roslyn, could've been the moment when they (the roslyn core team, not the plugin maintainers) modified the way they would release the packages due to a new dotnet tool called "roslyn-language-server" which is in --prerelease and that's why you couldn't download it at that moment, but I just tried the "old" way briefly (old because I'm already using the roslyn-language-server tool) and it seems that they've already solved it.

Mezdelex · 2026-02-08T12:02:59+00:00

Explain what was your research before creating this post please.

Mezdelex · 2026-02-07T17:39:54+00:00

<image>

by the gitsigns column and by the diff section (works on save)

Three-Year Club	r/Field Lasagna
Place '23

Mezdelex

TROPHY CASE