Replies: 11 comments 2 replies
-
I'll try to address these points
this has been a change that was imposed on us because nvim-lsp-installer was deprecated 1, I specifically created #2894 and had it pinned for two months 😞
you probably have not updated lunarvim in a very long time then, since that said, LunarVim/lua/lvim/lsp/config.lua Line 42 in 36c8bde
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
please don't confuse plugins breaking changes with the installer 😢
fair points! we can maybe revert some of these, but the rest should be manually marked as breaking in the changelog, @ChristianChiarulli.
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 the most likely solution for a stable release is using a packaged release that doesn't even Footnotes |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 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:
...which OK, I have no doubt is true but doesn't help me in any way. Finally, this:
...is great. Let's have that. If just periodically running |
Beta Was this translation helpful? Give feedback.
-
It's really not easy question . 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. The first one we must chage installation system from two links to config option like
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
With default configuration that we see on the home page. If you want to change something it will easy to
This make the config file more homonogenus and easy for configuration with the stable/develop plugins.
For all other plugins we can add flags "commit" or "*" for user own risks.
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. |
Beta Was this translation helpful? Give feedback.
-
Despite it being a rough ride here and there, LunarVim is an absolutely crisp experience when it does work. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
@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 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. |
Beta Was this translation helpful? Give feedback.
-
+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 |
Beta Was this translation helpful? Give feedback.
-
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. 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 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. |
Beta Was this translation helpful? Give feedback.
-
I think we recently resolved this on master @danielo515, uninstalling should leave your config alone now. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
<C-t>
to<C-\>
forToggleTerm
)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
Beta Was this translation helpful? Give feedback.
All reactions