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 :vimtutor to 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…
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*.
While I get the longevity argument (Vim and Emacs have a great track record), I’ve found that it is FOSS vs proprietary that causes beloved tech to die.
VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.
Another consideration for you is that Vim is, by a huge margin, the most popular tool for doing difficult edits in an ultra light or restricted server environment. It’s absolutely worth learning for that use case, which I keep being promised I won’t need again, between each of the hundreds of times I’ve needed it.
Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.
Btw, you make excellent points! Thank you for that. Much appreciated!
I’ve found that it is FOSS vs proprietary that causes beloved tech to die
There’s definitely truth in that.
VSCode is, by a wide margin, now the most popular IDE. If MS abandons it, there’s a fleet of us ready to continue using VSCodium.
I can definitely see that happen.
Edit: The usual issue with plugins on VSCodium, out of the box, is that it defaults to a completely different plugin set, due to MS license rules about their plugin repository. It’s trivial to switch it back with a config file edit, which is, admittedly, a little buried, in the project FAQ. The VSCodium plugin repository is growing better over time, but there’s not good awareness of it yet by most plugin developers.
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.
You could also consider: https://helix-editor.com/
It does more than vim out if the box and it has similar but different key bindings. The key bindings are more intuitive and easier to learn in my opinion.
It is missing a few features still (e.g.plugins) but I have been using helix for a while and it is really fun.
Helix is great. And it’s written in Rust so I feel pretty comfortable working in the codebase. The maintainers are friendly. I think it will eventually leave other modal terminal editors in the dust, considering rate of development.
It has shortcomings from being young, but they are rapidly disappearing. The philosophy of being mostly “batteries included” is so refreshing compared to the configuration hell of NeoVim.
And it’s written in Rust so I feel pretty comfortable working in the codebase.
Rust, indeed, is a big plus.
It has shortcomings from being young, but they are rapidly disappearing. The philosophy of being mostly “batteries included” is so refreshing compared to the configuration hell of NeoVim.
While its shortcomings might eventually be ironed out. Do you expect it to be as ubiquitous as Vi(m) has become? If not, do you expect Helix to improve its Vim implementation or rather become so popular that it can rival Vi(m) in being ‘ever-present’?
Do you expect it to be as ubiquitous as Vi(m) has become?
I honestly believe that Helix will eclipse NeoVim because it’s designed better, the source code is more maintainable, and the philosophy is a bit more balanced and welcoming to users that care more about productivity than customizability. Refactoring Vim’s spaghetti C code is a massive task, and C as a language drags it down. Where the NeoVim ecosystem is currently fractured among many Lua “distributions,” Helix just builds on itself in one source tree. I think starting with a solid core before supporting plugins will be good for the future of Helix.
do you expect Helix to improve its Vim implementation
I’m not sure what you mean. The Helix key combos are similar but not the same as Vim, they are closer to Kakoune. Once Helix has plugins, it might be possible to get something closer to true Vim emulation.
rival Vi(m) in being ‘ever-present’
Yea I think Helix is here to stay, and it will continue stealing market share from other terminal editors. It probably won’t convert anyone that’s already invested years in learning and configuring (Neo)Vim, but for newcomers looking for a powerful option with sane defaults, Helix is far easier to get started with.
Personally, I learned Vim at a workplace where most others used Vim. This was at a time when NeoVim was just gaining traction, so I wasn’t familiar with it. Vanilla Vim didn’t quite compete with VSCode for my workflows, so I worked with VSCode for a while before trying NeoVim. I found the NeoVim setup obtuse. Helix saved me all of that effort, and I was almost immediately productive.
Thanks for mentioning Helix! I’ve definitely considered Helix. But as ‘its Vim implementation’ messes the structure of its ‘sentences’, it seemed somewhat detrimental with respects to improving my Vi(m)-game. Furthermore, I am not confident that it will continue to thrive 20 years down the line; while both Emacs and Vi(m) have already proven with their respective track records how robust their ecosystems are.
It is missing a few features still (e.g.plugins) but I have been using helix for a while and it is really fun.
Which is another concern 😅. For whatever it’s worth, I believe Lapce to be more promising.
I think helix (or some derivative) has good long tern prospects. It has a fairly large communuty abd It is much more accessible than (neo)vim.
If you’re going to use NeoVim, use Kickstart.nvim.
It seems to offer a leaner approach. If you’ve used any of the ones mentioned in the OP, would you consider offering a more elaborate comparison between them?
I’ve used LunarVim and they make a lot of opinionated changes from the default behavior of NeoVim. These changes are undocumented and must be discovered and explored organically, while the default behavior is well documented.
It’s also difficult to update and change for your own use until you become familiar enough with all of the customizations and packages they’ve included.
Kickstart.nvim ads only a few packages that are very popular and provides a base upon which you can customize as needed.
These changes are undocumented and must be discovered and explored organically, while the default behavior is well documented.
This, indeed, is concerning. Thank you for mentioning this!
Kickstart.nvim ads only a few packages that are very popular and provides a base upon which you can customize as needed.
Hmm…, allow me to ask the following: How much effort would it take to get Kickstart.nvim from scratch to where any of the opinionated distros are in terms of functionality?
Oh! Emacs fanboy here!
I think that one of emacs’ surprising great points is that there is a plugin for a lot of smaller languages. If you’re working with a language that has no special text editor love at all you’re likely better off using vim but if the language authors made a plugin for their language, it’s likely either going to be for emacs or vscode.
As for distribution vanilla emacs Doom emacs. Spacemacs has a bespoke customization system involving layers that is not all that friendly towards copy & pasting code from the internet. Doom emacs customization leans more to the vanilla side which can help if you need to solve a problem in your workflow.
(Obviously vanilla emacs works best in that regard, but I can understand not wanting to start with default emacs straight away)
I think that one of emacs’ surprising great points is that there is a plugin for a lot of smaller languages. If you’re working with a language that has no special text editor love at all you’re likely better off using vim but if the language authors made a plugin for their language, it’s likely either going to be for emacs or vscode.
Very interesting. I didn’t know that Emacs was better at providing plugins. Would you happen to know to what that is attributable?
Spacemacs has a bespoke customization system involving layers that is not all that friendly towards copy & pasting code from the internet. Doom emacs customization leans more to the vanilla side which can help if you need to solve a problem in your workflow.
Did I understand you correct in that customizing Spacemacs is a completely different beast. So knowledge acquired related to it doesn’t translate well to Vanilla/Doom Emacs and vice versa?
Would you happen to know to what that is attributable?
Not sure but I suspect it’s 2 things:
- the default editor is kinda shit
- but it is really good at editing it’s configuration language: elisp
So people have a need to change their editor, and a good configuration language to do it in. Moreover, emacs secretly comes with a bunch of built-in features, not enabled by default. It also helps that emacs is not terminal-based, allowing users to do stuff in emacs that you aren’t able to do in a normal terminal (like viewing images, or searching for images on the web. Did I already say that emacs has a built-in (primitive) web browser?) and generally means that emacs users “live” in emacs, as they already have access to so many features.
If you compare this to vim
- good text editing experience by default
- vimscript wasn’t all that great (lua is better but neovim is still a very good editor so the drive to fix all it’s warts isn’t quite there)
- it is terminal based, so you can’t do some of the funny stuff that emacs allows you to do
Did I understand you correct in that customizing Spacemacs is a completely different beast?
Correct.
So knowledge acquired related to it doesn’t translate well to Vanilla/Doom Emacs and vice versa?
I wouldn’t quite say that. It is more that you are probably going to need some prerequisite emacs knowledge to make the best use out of spacemacs’ layer system. To figure out how spacemacs works, you first need to have a basic idea of how emacs works. Doom is a bit closer to the metal, so you need to know less in order to properly customize it
- the default editor is kinda shit
- but it is really good at editing it’s configuration language: elisp
So people have a need to change their editor, and a good configuration language to do it in. Moreover, emacs secretly comes with a bunch of built-in features, not enabled by default. It also helps that emacs is not terminal-based, allowing users to do stuff in emacs that you aren’t able to do in a normal terminal (like viewing images, or searching for images on the web. Did I already say that emacs has a built-in (primitive) web browser?) and generally means that emacs users “live” in emacs, as they already have access to so many features.
That makes so much sense. Would it be fair to say that Neovim attempted with Lua to bridge that gap and also make it a lot more accessible?
Did I already say that emacs has a built-in (primitive) web browser?
I don’t think you did, but I’m already aware. I even have some concerns regarding its sandbox 😅. Would you happen to know more regarding this?
I wouldn’t quite say that. It is more that you are probably going to need some prerequisite emacs knowledge to make the best use out of spacemacs’ layer system. To figure out how spacemacs works, you first need to have a basic idea of how emacs works. Doom is a bit closer to the metal, so you need to know less in order to properly customize it
That’s some excellent insight! Thank you very much, good human!
I like Doom Emacs
Have you used Spacemacs as well? If so, would you mind offering some more insight regarding either one of them and specifically whatever made you like Doom Emacs?
I think Crazazy had a good take about Doom in regards to customization. I’ll add that there’s some preconfigured plugins for most popular languages in Doom (complete with LSP) that makes it a breeze to go from install to feeling like home. You just have to uncomment them in the config file and reload emacs.
And one advantage is that, these plugins aren’t pre-installed, so they don’t load when you start emacs! Which makes doom emacs quite lean and the startup times are way faster.
I’ll add that there’s some preconfigured plugins for most popular languages in Doom (complete with LSP) that makes it a breeze to go from install to feeling like home. You just have to uncomment them in the config file and reload emacs.
That’s actually really cool! Thank you for that tip!
