A plea for stability

[vimpunk]

Problem description

This is a general issue rather than a report for any specific bug, as there have been too many to count. I have been using lvim for the better part of this year, and it has mostly been a great experience and I applaud the team for creating such an easy to use plug-and-play IDE experience for vim. However, in recent months after almost every lvim update my setup broke in various ways.

These have usually been breaking changes, ranging from small to big ones. Just a few examples:

• change in the default keymaps (e.g. the recent remapping of <C-t> to <C-\> for ToggleTerm)
• breaking previous rust-tools.nvim setup how to use rust-tools with mason.nvim? #2894
• introducing taplo, an lsp for toml (likely came with the mason change as far as I could tell), which started auto-formatting Cargo.toml files out of the blue (I never asked for it)
• introducing nvim-notify that spammed notifications with entire window overlays (what happened to appreciating the subtlety of the vim ethos?) remove nvim-notify from the core plugins #3294
• the installer breaking Cant install lunarvim "attempt to index field 'window' (a nil value) " #3290
• in a recent reinstall just now, with default config, the which-key key binding (leader/space) either doesn't work or has been remapped to a new key binding
• Rust development experience having become extremely fragile in the recent update. This may in part be due to rust-analyzer (which is unfortunately also known to break often), but I'm fairly certain something on the lvim side has been broken as well. I haven't had the time so far to do a proper bug report, but basically lvim would often freeze up during editing (often during saving), which is strange because to my knowledge the lsp-client is fully asynchronous and since I haven't added new plugins since this has started occurring, by process of elimination I have to guess that the issue was introduced through either an lvim or a ra update.
• auto-complete appearing in vim search which breaks c-n/p behavior
• lualine generating a mile of error messages that always pop-up randomly
• and many more, but I mostly forgot them or others have reported on them

With each release, I found myself spending about an afternoon fixing my config. The whole reason for my moving to lvim was that I no longer had time to maintain my own nvim config and so I had decided to leave it to people who are more passionate about and more involved with the recent developments of the nvim ecosystem. A dev's editor is their number one tool and it must be absolutely rock solid and never even give the faintest impression that it cannot be relied upon. This is what I'd desperately like LunarVim to be because I love the idea and have for the most part enjoyed using it.

To offer something of constructive value too, I'd suggest to be more conservative with the breaking changes (key remaps, new plugins, etc) and test any breaking changes for an extended period in the release channel. I'd even go so far as leaving new breaking changes opt in by default and documenting them religiously. That way, even if one updates lvim from within their editor, they won't expect it to break or change behavior in completely unexpected ways the next time their relaunch lvim.

LunarVim version

master-36c8bde

Neovim version (>= 0.8.0)

NVIM v0.8.0

Operating system/version

macOS 12.6

Steps to reproduce

default install will do

[kylo252]

I'll try to address these points

breaking previous rust-tools.nvim setup
Rust development experience having become extremely [ .. ]

this has been a change that was imposed on us because nvim-lsp-installer was deprecated ¹, I specifically created #2894 and had it pinned for two months 😞

introducing taplo, an lsp for toml (likely came with the mason change as far as I could tell), which started auto-formatting Cargo.toml files out of the blue (I never asked for it)

you probably have not updated lunarvim in a very long time then, since taplo has existed since January, see williamboman/nvim-lsp-installer@264d499

that said, toml is a very good candidate to be added to the default skipped list

LunarVim/lua/lvim/lsp/config.lua

Line 42 in 36c8bde

local skipped_filetypes = { "markdown", "rst", "plaintext" }

introducing nvim-notify that spammed notifications with entire window overlays (what happened to appreciating the subtlety of the vim ethos?)

nvim-notify was added back in November last year, specifically in https://github.com/LunarVim/LunarVim/releases/tag/0.6.0, but it has been removed as of #3300

the installer breaking #3290

please don't confuse plugins breaking changes with the installer 😢
it was cmp that deprecated those options, see hrsh7th/nvim-cmp#936

change in the default keymaps (e.g. the recent remapping of <C-t> to <C-\> for ToggleTerm)
in a recent reinstall just now, with default config, the which-key key binding (leader/space) either doesn't work or has been remapped to a new key binding
auto-complete appearing in vim search which breaks c-n/p behavior

fair points! we can maybe revert some of these, but the rest should be manually marked as breaking in the changelog, @ChristianChiarulli.

I'd suggest to be more conservative with the breaking changes (key remaps, new plugins, etc) and test any breaking changes for an extended period in the release channel.

this has mostly been the case, but we've recently decided that master should be displace rolling, and stable releases are tags only. this also introduces a problem with how LvimUpdate is supposed to work and how hard it is control this and maintain stability in this command both forward and backward in time 💀

the most likely solution for a stable release is using a packaged release that doesn't even LvimUpdate. this should theoretically be much easier since #3161, but then again we need the community support for all of these https://github.com/LunarVim/LunarVim/issues?q=label%3Apackaging

Footnotes

1. https://www.reddit.com/r/neovim/comments/w6w5ij/introducing_masonnvim/ ↩

[Lun4m]

but we've recently decided that master should be displace rolling, and stable releases are tags only.

Why is this not written explicitly anywhere (except in this comment)? This has to be properly communicated (in the readme, in pinned issues/discussion, etc.), especially since people expect master to be "stable".

[vimpunk]

Thank you for addressing my points in such detail. :)

Fair points. I definitely must have missed important announcements and pinned issues, but as said, I haven't had time to do any open source recently, which I also think is one of my main points: the editor should ideally remain stable even for those who are casual users and don't keep up with lvim development. I understand this is hard to achieve in practice when core plugins get deprecated.

As another suggestion, I'd add a popup or info log to the in-editor updater (if you guys do decide to keep it, although a packaged release model would work nicely too) that lists the breaking changes and new additions. I think this would be extremely helpful in being able to discover any config changes that need doing on the user's side.

I'll keep thinking about other suggestions, thanks for being open to having this conversation. I'll try to find some time to help out too if I can identify specific tasks.

[dimitarvp]

TL;DR: Please either make a conscious effort for your users to never see cryptic Lua stacktraces or just point us at a rock-solid installation that never does this (as much as possible, within reason).

---

I am 99% with OP here except auto-formatters, I absolutely love these and they rid me of having to manually fling code around to be compliant with whatever some committee deems a best practice -- so let's have auto-formatters for every file type, please!

I am a VIM novice and got attracted by NeoVim's announcements a year or so ago. I don't have the time, and sometimes the energy, to manually fix LunarVim after each breaking change, and as OP said they have been more and more lately. More often than not I simply stop using LunarVim for a month and if the problem was still not fixed after a few manual LvimUpdate commands then I begrudgingly go on the net to try and fix it -- which often results in full reinstall. Which means I have to backup my init.lua somewhere and then only put relevant parts of it in the new variant of it. Etc.

Again, I am a VIM novice, and this has been super annoying.

If the team believes VIM novices are not welcome then I guess that's that but I'd like to know if that's truly the case. I'd like to see it said somewhere.

However, as a senior dev I am also a bit disappointed. A lot of us have to make a conscious effort to maintain old stuff. If there's a breaking change then I'd expect there to be code somewhere checking if a plugin is now removed and if so, migrate config to the new thing. Not bail with a Lua stackstrace and certainly not just throw your hands in the air and say this:

please don't confuse plugins breaking changes with the installer 😢
it was cmp that deprecated those options, see hrsh7th/nvim-cmp#936

...which OK, I have no doubt is true but doesn't help me in any way.

Finally, this:

the most likely solution for a stable release is using a packaged release that doesn't even LvimUpdate.

...is great. Let's have that. If just periodically running LvimUpdate is considered advanced workflow that requires intimate NeoVim knowledge then OK, I will not do it. I'll just schedule time to check for a new release 1-2 times a month, write a shell script that is doing it (assuming no breaking changes) and be on my merry way.

[kobzar]

It's really not easy question .
From one side, the newer users of lvim/nvim/vim is absolutly right. They must have the variant to install and working with LunarVim from box like any other code editor. And LvimUpdate command doesn't must to broke the lvim. Just one exception - when release is changed with readme informations about changes. So, we must have really stable version and developer version for advanced users.

From other side, more progressive users want to use fresh versions of plugins, actions, e.t.c

So, the best variant use something like linux repository system for plugins. As i know the core plugins is freeze now, but external isn't. Thats why we have a lot of problem after updates. The external plugins changes every days.
If we change something in core plugins (remove/update/change default configuration for it) - the release must be changed with descr.

The first one we must chage installation system from two links to config option like

lvim.version = "stable"  -- by default

if we are change it to lvim.version = "develop/rolling" the plugins will updated.

The next one, it's add all external plugins from home page external list into lvim core but dont make it active by default. So users can enable it easy like

lvim.builtin.rust-tools.active = true
lvim.builtin.neoscroll.active = true

With default configuration that we see on the home page. If you want to change something it will easy to

lvim.builtin.neoscroll.stop_eof = true -- like for core plugins

This make the config file more homonogenus and easy for configuration with the stable/develop plugins.
(i suggested it before )
Ofcource some one want use stable version of lvim but use some fresh version of plugin. No problem, we can use the same flags for it (by default plugins use version of lvim) so for stable lvim with fresh neoscroll it can look next

lvim.builtin.neoscroll.version = "fresh/develop/unstable/etc"
lvim.builtin.neoscroll.active = true
lvim.builtin.neoscroll.stop_eof = true

For all other plugins we can add flags "commit" or "*" for user own risks.

lvim.**user**.plugins = {
      { "fdefe46c6807441460f11f11a167a2baf8e4534b", "arkav/lualine-lsp-progress"}, -- specifycal version
      { "*", "marko-cerovac/material.nvim" }, -- last known version
}

This is not resove all of issues, but for my opinion make lvim more stable and easy for new users.

But. All of us must understand that LunarVim is free open and young project with small count of maintainers.
So its need more time and users feedbacks to make it better and stable.

[RizaHKhan]

Despite it being a rough ride here and there, LunarVim is an absolutely crisp experience when it does work.

[jukrb0x]

The APIs are constantly changing, every time I upgrade the old configs are not working, the ultimate solution is to uninstall it entirely and install lvim again, and migrate for myself.

i just wondering where are the standards for API / RFC. if have to change them so frequently, can introduce some version migrating tool? i guess there must be some way to do it.

the version quote 1.x which is not so true, it should be marked 0.x for so many unstable changes.

[dimitarvp]

@kobzar Absolutely great suggestions, thanks for laying them out.

I think we here are aware the project is young and is understaffed -- like most open-source projects, sadly.

Let's have a stable static version that can be updated only via e.g. GitHub releases (and people can subscribe only for new releases so they get an email when you push out a new version), maybe with plain old versioned .ZIP files. And yep, you can even disable the LvimUpdate command in it, I don't think anybody using the stable version would mind. Or change it to simply checkout the next tag / download the next release, unpack it in place and reload LunarVim.

I think what happened is that people treat LunarVim as an IDE that's always working out of the box and that comes with the expectations seen in this discussion.

I'll enjoy learning NeoVim in much more detail sometime in the future but right now I don't have the time and the energy. So I'd love a non-surprising update experience.

[gonzaloserrano]

+1. I upgraded and now I got mason which has its own binary directory that's not in $PATH, and my go tools (i.e gopls) are now in a different location / version 🤦

[LostNeophyte]

mason adds installed binaries to the neovim's PATH

[danielo515]

As someone that has contributed to Lvim a couple of times, and that has more or less a good understanding of its internals, I still find frustrating the updating experience.
Almost a couple of days after start using Lvim, I also started using chezmoi. Why? Because 80% of the times, the only way to fix a bug in LunarVim was to completely uninstall and re-install it, and that was erasing my configurations, so I decided to have them live outside, safe out of the reach of the installer.

As people has mentioned, breaking changes are becoming more and more common, and not for the good reasons. Sure, some were unavoidable, like moving to mason.nvim after the deprecation of previous solution, but a lot others are just maintainers personal preferences introduced as breaking changes: deactivating format on save, removing the default bindings for H and L, removing vim notify, changing the way autocommands are set, etc... sure those changes make some users happy, but also surprised a lot more that were either already used to that or that already had workaround it.

I agree that external user plugins are a nasty source of problems, that's why I created a function for the sole reason of pinning my plugins to the current version I use, and it's been a great experience so far. I could open a PR to add this userland plugin pinning to Lvim, but I already have 2 or 3 PRs frozen waiting to be merged, and I don't feel like putting time and effort into something that could be ignored for months if not for ever, and that is another problem of the project.

[ChristianChiarulli]

I think we recently resolved this on master @danielo515, uninstalling should leave your config alone now.

[brneor]

I like to add that despite breaking every now and then, LunarVim was the sole responsible for finally making me want to use vim. It improved my productivity in many ways and for that I'm thankful.

As a sign of gratitude, I've switched to rolling (now master) months ago and tried to report any disruption of my workflow to help keep LunarVim a great tool.

Thanks @ChristianChiarulli and every single collaborator of the project.