However, if you were entertaining the idea of slowly switching to Zig, the build system would be the place to start. Moving away from CMake is worth it even if you don't push it further.

But yeah, the C-Zig interop story is so good it's a no brainer if you want to "modernize" your C codebase, and you can do so incrementally instead of stopping the world for a rewrite.

why "slow" just re-write it with ai. and to be clear im 0% joking and am prepared to be downvoted by people who haven't yet understood how feasible this kind of thing already is and how utterly trivial it will be in the near future

Any rewrite is massive friction, I’m sure probably meant port? The only annoyance with Rust ports is if you have to support varargs. Hopefully that will come to an end soon.

Sadly, this is the general trend with neovim in general: less focus on stability, more and more focus on shiny new things. If I didn't have an nvim config that I'm used to I would have switched to plain vim ages ago.

The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.

To be clear, it's fine to have breaking changes. Especially if you're working towards something substantial.

But nvim and its plugin ecosystem seem to be altogether too keen to change absolutely everything and adopt all bleeding edge developments. Even when a mature system would serve the purpose just as well.

But the UI is also an interface, and the user is part of the total system. That system interface is broken if you change default mappings.

It doesn't matter if the interfacing component is software or a user.

https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....

I'd guess if you don't care about lazy loading and OK with just loading everything all the time - vim.pack is great to have as a built-in.

That being said, there is a way to lazy-load the plugins — Evgeni has a guide for that [1]. The "Load not during startup" variant is really simple with putting `vim.pack.add()` into `vim.schedule()`. The other myriad of options (keys, cmds, event) that lazy.nvim provides would require you to set up appropriate autocommands.

It gives me vibes of writing in Go. Everything is right there — builtin — but there's some verbosity to bear with.

[1]: https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....

``` vim.api.nvim_create_autocmd("User", ... ```

But it only solves the actual lazy part. Not sure how you can solve defining plugin dependency graph for such loading that lazy.nvim allows.

I can try experimenting with it anyway.

    std::vector<std::string> split(const std::string& text, char delimiter) {
        std::vector<std::string> parts;
        std::istringstream stream(text);
        std::string part;
        while (std::getline(stream, part, delimiter)) {
            parts.push_back(part);
        }
        return parts;
    }

    std::views::split(my_string, delimeter)

?

I will agree that std::ranges is quite a jumble of templates, and has a compilation time penalty. Perhaps the use of modules will help with that somewhat.

What do you mean by that?