Thank you for touching upon some of LunarVim's 'oddities'!
throwawayish
joined 2 years ago
If you like VSCode, and want the longevity of FOSS, you can switch to https://vscodium.com/
For some reason I had a very bad experience with running plugins on VSCodium. IIRC, there was something about plugin support being a lot worse for some reason. But it might also have been related to something else.
The Vim keybindings for VSCode/VSCodium are ridiculously good
It indeed seems to be a lot better than what I was expecting.
As a diehard Vim user, VSCodium with VSCodeVim is a terrific no-nonsense combination.
But, once again, I'm afraid that eventually VS Code (and thus by extension VSCodium) will be forsaken for some reason. Thus making me, once again, deal with the pain of switching to another IDE, become accustomed to it. Not being as extensible as Emacs/Neo(Vim) anyway etc etc. Like, I believe we're always one 'evolution'/'development' removed from losing our favorite IDE. For example, Jetbrains has been developing their upcoming Fleet IDE. IIUC, it's their version of VS Code; which honestly is cool. But, does beg the question if it will one day replace the fleet of dedicated programming language IDEs that Jetbrains currently supports...
EDIT: lol I only noticed you had edited it after I had commented it.
Edit: Regarding Vim plugin packs, I honestly only ever had a bad time with curated plugin collections. I don’t think the default settings in Vim are that bad anymore, and are trivial to change as you go when something annoys you.
Would that only include Vim plugin packs like SpaceVim etc? Or actually the premade NeoVim 'configs'/'distributions'?
Regarding the ‘split’ in Vim options, Vim is growing up into a protocol, rather than just an editor. As a ‘trapped in Vim’ user, back in the day, I’m delighted that essentially every serious editor now supports Vim keybindings*.''
True. Great insight. But, it sometimes seems to me as if most implementation are rather lazy ones; in the sense that they only feature a very small feature set that Vi(m) provides. I might be wrong though*.
I have used vim/neovim for years and cannot go back to a non-modal editor. But TBH I got sick of its configuration. You need far too many plugins and config to get things into a sane working order to be usable on a day to day bases for any type of development. It takes ages to learn and become as productive as you were before and a lifetime to refine.
Interesting. Though I can definitely see where you're coming from. Uhmm.., have you used any of the Neovim distributions to make maintenance easier?
For the past year or so I have switched to helix and don’t plan on going back to vim/neovim as my main editor ever again.
Both Helix and Lapce have certainly piqued my interest as FOSS alternatives to VS Code. However, both have issues related to how well their current Vi(m) implementation is. As you've touched upon it; Helix' keybindings and 'sentence-structures' are different to those found on Vi(m).
Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there's no guarantee that I can keep using either of the two 20 years into the future. While no program is able to 100% guarantee that, undoubtedly, the track records for both Emacs and Vi(m) testify that -if anything- they would be the most likely ones to survive 20 years down the line; like how they've done for the last couple of decades.
I appreciate the input, but I simply don't want to invest in a program whose future is very unclear to me at this point in time.
It’s not my main IDE, mainly due to working with Java dev and needing a debugger.
I thought debugging was taken care of by nvim-dap and similar plug-ins. I suspect they aren't as feature-complete then compared to those found on 'real' IDEs. Or is it perhaps something else?
eMacs is better used as a standalone application than in the terminal.
Yeah, support for using Emacs within a terminal is mainly there for legacy purposes if I remember correctly. But IIRC Neovim also allows usage outside of the terminal. Which begs the question; what functionality does this bring to the table for Neovim?
My primary use for emacs is org mode.
I haven't even started using Emacs extensively, but from what I've seen it definitely seems to be its killer function. Though, I'm interested to know if you've tried using Emacs as an IDE? If so, how did that go?
Thanks! Those should provide some decent pointers.
Would it be a fair assessment to suggest that LunarVim was chosen primarily for the fact that it came out first? Like, either one Astronvim, LazyVim and NvChad might have done a similarly great job, but you were already using LunarVim and saw no reason to switch as the functionality they provide is relatively close to one another.
Furthermore, because you were already accustomed to Vim, you were able to properly utilize LunarVim as a startingpoint. As such, switching from startingpoint would only amount to more work without any real benefits.
I use lunarvim almost exclusively.
Was it a very conscious choice? Like have you tried the others but (somehow) didn't like them etc? And if so, why do you prefer LunarVim over the others?
Nah, no need to worry. I've got a friend that was bad at math and therefore dismissed a career as programmer initially. Eventually, he just couldn't ignore how much programming interested him and did start a Bachelor's degree in Computer Science (after disliking his first year of Finance). A couple of years later and he's the proud owner of a Master's degree in Computer Science while still being relatively bad at math, but it didn't stop him. Nor should it stop you.
openSUSE's Richard Brown has given multiple talks over the years comparing these three. I'd suggest anyone to look at those for a great rundown on how these universal package managers compare to one another. His most recent talk can be found here; in which he actually does some kind of recap as well.
A couple of assumptions I will be making:
- Your hardware is supported; consider to check driver support over at linux-hardware.org. Honestly, most hardware should be well-supported, unless it has been released very recently or is hardware from known troublemakers (i.e. Nvidia GPUs or Broadcom etc).
- Your 'computer-literacy' is at least (slightly) higher than average.
- You've primarily used Windows in the past.
- You prefer asking others instead of finding it out for yourself; the existence of this post supports that. (It's either that or you like to have a second opinion in all cases; but I would have expected more input from you if that was the case 😅.)
- Your hardware is somewhat modern.
- You will mostly stick to defaults (at least initially).
- You're aware that while hundreds of actively maintained distros exist, most of them are either niche or not worth your time in the first place. If, from the remaining ones, the less impactful derivatives are surgically removed, followed by the removal of newbie-unfriendly distros, then only 10-20 distros would remain; most of which have been named in this thread already. And your needs dictate which one out of these would suit you best.
- You will educate yourself regarding desktop environments like GNOME, KDE Plasma, Cinnamon, Xfce etc. Perhaps you will even boot into a live environment to check them out for yourself; loading a bunch of distros on your USB through Ventoy is excellent for that. This is important as they're arguably the biggest contributor to how you perceive your Linux system. You should also be aware that in almost all cases a second (or heck; even third, fourth etc) desktop environment can be installed on your system and you should be able to switch between them relatively easily. However, in most cases, the one provided on first installation works close to flawless while others that have been tacked on later on are generally less polished.
- You will educate yourself (eventually) regarding universal package managers (read: AppImage, Flatpak, Nix and Snap) and Distrobox as collectively they've (mostly) ridden the Linux ecosystem of problems related to software not being packaged in the native repos. Don't feel the need to indulge into all of them simultaneously from the get-go. But be aware that they exist and that they enable one to install (almost) any package that has been made available to Linux regardless of their chosen distro.
Any distro I should use?
Typically, distros like Arch, Debian, Fedora, Linux Mint, openSUSE, Pop!_OS and Ubuntu (or their derivatives) will be mentioned in these kinds of queries. And it becomes mostly a popularity poll that measures what the community thinks is the preferred distro for beginners. And honestly, I don't blame them as you haven't really given us a lot to work with. My entry to that popularity poll would be Linux Mint. If you prefer to use GNOME or KDE Plasma instead, then consider either Fedora or openSUSE Tumbleweed. Additionally, Pop!_OS should be considered if Nvidia causes problems on all the others.
Feel free to inquire if you so desire!
EDIT: I just noticed how you mentioned to someone that your use case will be primarily gaming. First of all, gaming is somewhat equal on most distros; especially with the likes of Bazzite-Arch and Conty providing excellent environments for gaming regardless of installed distro. Though, these containers do still rely on the hosts kernel, therefore any perceived difference on same hardware but different kernels might be attributed to said kernels. Newer kernels generally come with improved performance; at least for newer hardware*. Though, perhaps more performance could be gained through other means as well. I will spare you the details, however, as this is potentially another rabbit hole within the initial rabbit hole. Therefore, instead, I will name a couple of distros known for being excellent for gaming purposes: Bazzite, Garuda Linux, Nobara Linux, PikaOS and RegataOS. If you want a no-nonsense system, just go for Bazzite; while initial setup might seem slightly more involved, it's by far the most robust system out of these. This does come at the cost of being 'unique' amongst the others, but I believe it's a great fit for your use case.
I’ve had a bit of a look into Tumbleweed and it sounds like it’s similar to Fedora in how it handles packaging of proprietary software which I found pretty annoying, but I could be wrong.
It's true that Arch is leaner towards proprietary software if that's what you mean. An example of this is how the Nvidia drivers are just found within repos for Arch (thus enabled by default), while on both Fedora and openSUSE it's not found in the official repos. Both have made it easier over the years to somehow include options and whatnot within the installer to ease Nvidia users in, but the experience on Arch is definitely smoother.
Furthermore, Fedora is indeed (kinda) hardcore on FOSS, similarly to Debian. While Arch simply doesn't care in most cases. My relatively short endeavor to find out where openSUSE fits in seems to point towards openSUSE leaning closer to Debian and Fedora.
What's perhaps important to note is that in all cases there are third party repos that can easily be enabled to acquire proprietary software.
That was perfect! Thanks for sharing.
Thanks for your kind words. Much appreciated! 🙂
It does sound alot like they are taking time tested designs that have been in use in the datacenter & Infrastructure side within virtualization offerings for years
To be honest, I'm absolutely clueless on any of that 😂. So, unfortunately I don't feel confident to talk about that. Would you be so kind to enlighten me?
Btw, you make excellent points! Thank you for that. Much appreciated!
There's definitely truth in that.
I can definitely see that happen.
Wow! Thank you so much! At the time I just needed something that works, so the path of least resistance (read: go back to VS Code) was preferred. So, I probably didn't even bother finding a way to resolve the issue at the time. But this paragraph has provided a great amount of pointers that will surely help solving it.
Perhaps I should include VSCodium as another viable alternative 😜. So that it becomes -at the very least- the path of least resistance to Emacs and/or (Neo)Vim.