cross-posted from: https://lemmy.ml/post/9648279
I would like to premise this with the following:
- The best approach is probably just testing out each and every editor that interests me until I’ve found what works best for me.
- However, I wonder to what degree a test as such would be representative when the likes of Emacs and (Neo)Vim are considered; both of which are known for being a life time learning process.
- I don’t literally expect Emacs or (Neo)Vim to be drop-in replacements for any IDE. Some of the most basic IDE-functions are absent by default and some (perhaps more advanced) functionality might simply not be attainable at all.
- I am not interested in anything that remotely resembles a flame war. The community at Lemmy has so far been very kind to me; let’s keep it that way 😜.
Motivation
I’ve had experiences with Atom, VS Code and some of Jetbrains’ IDEs like Pycharm and Rider. While I’ve been generally content with all of them, it leaves a bad taste in my mouth whenever I’m forced to switch IDEs because their lifetimes and/or lack of extensibility doesn’t allow me to responsibly continue using them. As such, I’m interested in a long time investment that will grow as I will. Both Emacs and (Neo)Vim have passed the test of time and I honestly don’t think they’ll cease to exist in the upcoming decades, that’s why I would love to start using either one of them.
Furthermore, Vi(m) keybindings seem to be somewhat ubiquitous and almost any IDE offers some support. As such, improving my Vi(m)-game should only net-positive my productivity (at least eventually). Also, fluency will benefit me whenever I’m remote accessing any random server as they will always have Vi(m) installed. Thankfully, this doesn’t force me to use Vi(m) (or Neovim) just yet, because Emacs offers with Evil perhaps the single best Vi(m) implementation; outside of native Vi(m)*.
My setup:
- I’m on a custom image of uBlue using their startingpoint as template. For those unaware; an oversimplification would be that it is Fedora Silverblue with some extras.
- As such, I would like to have my developer environments local and have used Distrobox to that extent using steps similar to the ones outlined over here. But I’m not married to that specific way of utilizing local containers. So please feel free to recommend me something that’s at least as good.
- If I go for Emacs, then I will definitely rely on Evil.
- If possible, I would like to use it for C#, Python and Rust. Furthermore, I engage in editing Bash scripts, Dockerfiles, Linux config files, texts written in Latex and/or Markdown and other files written in Nix or JSON. As both are very extensible, I don’t expect any issues, but I might be wrong.
Questions:
- First of all, does it make sense for me to only consider these two?
- Can the split between Vim and Neovim be interpreted as the first schism and as such be a forebode for what’s yet to come?
- Google Trends suggests that Neo(Vim) is ever-popular. On the other hand; not only is Emacs relatively less popular, but its popularity seems to be slightly declining. Should this worry me regarding their long-time future? Especially considering that a thriving community is literally the lifeline for both of them.
- For those that have used both extensively, which one do you prefer (if any) and why?
- While I understand that the power of both of them lies primarily in how one can literally make them behave however suits their workflow best. Therefore, the use of premade configs and/or starter kits/distributions should (ideally) only be used either temporary or as a starting point. However, at this point, they provide a decent showcase of what each ‘platform’ has to offer. So:
I’ve been using code editors for over 40 years. I’ve gone back and forth between Emacs and NeoVim/Vim. The last five years has been extensively Neovim since it is faster than Emacs. On Emacs, I’ve loved DoomEmacs. It’s the fastest on Emacs. I prefer NeoVim over Vim because it is faster (especially when using plugins with Lua or Python). In NeoVim, I’ve used all the mentioned setups and have settled on LazyVim due to it’s starting speed and ease of changing configurations around. LazyVim also requires the latest NeoVim, but it is worth upgrading to it. I use bob to manage my NeoVim versions and mostly I use the nightly version without any hiccups.
I’ve been using code editors for over 40 years. I’ve gone back and forth between Emacs and NeoVim/Vim.
Wow, a veteran! Thank you for sharing your insights!
In NeoVim, I’ve used all the mentioned setups and have settled on LazyVim due to it’s starting speed and ease of changing configurations around.
That’s very valuable information! If it isn’t too much trouble, would you mind offering me a short rundown of what you think of each?
LazyVim also requires the latest NeoVim, but it is worth upgrading to it. I use bob to manage my NeoVim versions and mostly I use the nightly version without any hiccups.
Noted.
I use lunarvim almost exclusively. It’s fast, has great defaults and with the right lsp Plugins installed, it supports most languages. It’s based on the more recent versions of neovim, so e.g. standard debian version would require an upgrade.
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?
I had become heavily into vim, but needed something easy to set up as I no longer have time for tinkering, and also wanted to replace so called ide’s with something in my terminals. Paired with byobu for terminal multiplexing, I rarely need to leave my terminal. As an aside, I am also toying with ollama in a byobu split as my sme/ man page wrangler for when I’m too busy to waste time looking for the exact syntax it library to do what I want. Working well so far
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 recently (couple months ago) switched back to vim after not using it for anything but quick little edits for 20ish years, but i grew up on vim in the 90s.
Like the other poster i picked lunarvim for my neovim starting point. Thought I’d try others too, but lunarvim’s defaults were nice enough that I just kept honing the config after that and never got around to trying anything else because i was already really happy with my setup.
Lunarvim is a really good base. It does have some gotchas, such as having its own way of defining keybinds, and having a completely separate config folder in ~/.config/lvim, and a few other config things that are specific to lvim, but it’s all well documented on lunarvim’s site.
Thank you for touching upon some of LunarVim’s ‘oddities’!
For what it’s worth, even with those oddities, i think you should at least try lunarvim.
The separate config thing is nice because i can try neovim+other-megaplugins without affecting my precious lvim config. the same is true on the other side, lvim won’t bonk your core neovim config.
And with the keybinds, it’s to make sure the sub-plugins work well together. using lvim’s custom key config helps keep all your plugins from interfering with each other.
Legit, especially if you’re going to modern vim from a modern gui ide, lunarvim will get you really close to a comfortable environment, and you can move on from there to perfect it for your own needs.
Thanks a lot for your input! It has been much appreciated!
The separate config thing is nice because i can try neovim+other-megaplugins without affecting my precious lvim config. the same is true on the other side, lvim won’t bonk your core neovim config.
That’s indeed very useful!
And with the keybinds, it’s to make sure the sub-plugins work well together. using lvim’s custom key config helps keep all your plugins from interfering with each other.
Makes a lot of sense!
So far, based on the comments, it seems as if LunarVim does have the biggest community (or at least the most vocal one 😜*). Which is honestly pretty cool to see!
To use any editor with vim bindings takes time and effort. The learning curve is generally quite steep, so if you decide to go down that path, then to switch to a different flavour of vim isn’t too much effort, assuming you have already put the effort in to learn vi/vim/nvim. If you have yet to do that, I strongly suggest that you go dive into using vim for a month or three before you start worrying about which plugin set you prefer. The magic powers are really in the modes, macros and keybindings. For example, VSCode has a decent enough set of keybindings that it’s usable, but I still prefer console editing and on the fly macro creation.
Regarding Lunarvim, for me, it was the first vim ide I found which hit all my requirements, and wasn’t intellij, vs code, etc. But I had been using vanilla vim for nearly 30 years by then. The default plugins which come with lvim are pretty good, so I only add or modify with care. I really can’t afford to lose my ide in a work environment.
Speaking of which, lvim works in most terminal environments, but may require font tweaking on windows, wsl, etc. But then it’s always harder doing stuff in those environments…
I can’t speak for emacs, since I last tried it 20 years ago (although I didn’t like the complex key bindings at the time). I hear that once you commit to one of the two, it’s difficult to transition to the other, but ymmv 😁
If you have yet to do that, I strongly suggest that you go dive into using vim for a month or three before you start worrying about which plugin set you prefer.
Noted. Thank you!
For example, VSCode has a decent enough set of keybindings that it’s usable, but I still prefer console editing and on the fly macro creation.
Very interesting. Would you mind elaborating?
Speaking of which, lvim works in most terminal environments, but may require font tweaking on windows, wsl, etc.
A few weeks ago when I tried LunarVim for the first time, I had trouble assigning a different font for it than the one I prefer using in the terminal otherwise. A quick search didn’t bear anything that I could use to resolve the issue. Would you happen to know if it’s possible to assign a different font to LunarVim (or any Neovim distribution for that matter) than the preferred one to use in the terminal?
Re macros. If you are editing something and you need to repeat a pattern, eg. Remove every third line or whatever, you just get to your start point and press q<a character> in command mode to start recording into macro buffer <character>. Q to quit then you can reuse it and use it as a command with @<character> Re fonts. It’s your terminal which controls your font in windows. In wsl, eg. The font is controlled by the external windows terminal and not by wsl. It’s dependent upon your environment I’m afraid.
Thank you so much for all the lovely insights you’ve provided! Have a good one ☺️!
Re macros. If you are editing something and you need to repeat a pattern, eg. Remove every third line or whatever, you just get to your start point and press q<a character> in command mode to start recording into macro buffer <character>. Q to quit then you can reuse it and use it as a command with @<character>
That’s so cool!
Re fonts. It’s your terminal which controls your font in windows. In wsl, eg. The font is controlled by the external windows terminal and not by wsl. It’s dependent upon your environment I’m afraid.
Hmm…, that’s unfortunate. Hopefully I can find a work-around.
