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:
If you like VSCode, and want the longevity of FOSS, you can switch to https://vscodium.com/
It still leaves the option of using non-FOSS plugins, but makes it much more obvious which bits are FOSS or not. It is, otherwise, an identical experience with VSCode.
The Vim keybindings for VSCode/VSCodium are ridiculously good: https://github.com/VSCodeVim/Vim
As a diehard Vim user, VSCodium with VSCodeVim is a terrific no-nonsense combination.
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.
So ratherb than picking a plugin pack, I recommend spending some time in
:vimtutorto learn about various quality of life settings, and then set them as you prefer in your.vimrc.Edit 2:
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*.
*Disclaimer: I will ‘no true scottsman’ all day long if someone names me a ‘serious editor’ without Vim keybindings. Let’s all not go there, I’m too childish for that conversation.
One important thing you should know about Vim is that, VimScript, the native way to extend the original Vim, is an unholy abomination that is best left to rot in it’s forgotten grave. It’s the only reason I moved on to VSCodium, which can be extended with TypeScript, an unholy abomination that looks like it’s going places.
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…
I like Spacevim a lot (inspired by SpacEmacs), you can use neovim as the underlying vim package as well. Then update init.toml with whatever layers/plugins you want
I like Spacevim a lot
Have you tried any of the ones mentioned in the OP? If so, would you be so kind to elaborate upon why you prefer SpaceVim over the others?
(inspired by SpacEmacs)
Interesting. Would you be so kind to elaborate on what this entails?
you can use neovim as the underlying vim package as well. Then update init.toml with whatever layers/plugins you want
That seems kinda hella streamlined and straightforward, which is honestly pretty cool. Is this different from how it works on any of the ‘(Neo)Vim distros’ and/or by default?
I’ve tried a few IDEs, mainly Microsoft ones as of recently, but I still prefer my neospacevim setup. Microsoft has a very nice debugger and other useful features for navigating large software projects, but even on my 3080 12th Gen i7 rig with 32GB the plugins I use end up slowing things down. Plus, a similar debugger interface can normally be found in an init.toml layer
With neospacevim, I can specify which plugins get loaded for which file types, so my LaTeX plugins don’t interfere with my Python plugins for example.
Also the macro language locks me into vim, I even installed vimium keybinds for my browser. Spacevim is nice because you can see all the available keybinds option trees by pressing Space.
I mentioned spacevim/SpacEmacs because your post focused on emacs/vim, if you do choose either to make an IDE in I would imagine SpacEmacs/spacevim might be a little closer to an IDE than a text editor.
Spacevim is nice because it will auto install packages declared in the init.toml, sometimes with vanilla vim or neovim you need a plugin manager installed separately
