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:
Interesting. Though I can definitely see where you’re coming from. Uhmm…, have you used any of the Neovim distributions to make maintenance easier?
I have, but dont like them. They all have weird install processes and need to manage their own set of configs on top of vim in your home dir. This makes them very hard to properly package or integrate with config management tools and require a different flow to keep them up to date from the rest of your system. They combine sometimes hundreds of plugins, of which only a few are designed to work together and while a lot don’t try to step on each others toes that many I often find issues in niche use cases. And when you do find an issue, or something you want to tweak you have 100s of plugin configurations that you need to learn about to figure out just what is doing what and which options you need to tweak.
It is all just far more hassle then I want out of my editor these days. Helix just works out the box and has basically everything I want from a editor nicely integrated into it.
As you’ve touched upon it; Helix’ keybindings and ‘sentence-structures’ are different to those found on Vi(m).
They are a little different and take a bit to get used to. But IMO I find them far nicer way to work. It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys. And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often. It is not trying to be a 100% vim compatible layer, it is trying to give you the best experience it can out the box. And I think it does that quite well (at least once you get used to the new way of working - which does not take that long).
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.
20 years is a long time. I can see it existing for the next 5 years at least, and looks to be on the trajectory to be a long lasting product. Though no one can say for sure. But, the more people using it the more likely it is to stick around for the long term. Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).
And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.
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.
The investment in helix is far less then that you need to put into vim/neovim due to all the configuration you need for them. Well worth it for how active it currently is and how many people are putting effort into it.
Wow! Excellent and thorough response. Thank you so much for taking your time 😊!
It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys.
That’s awesome! Which does beg the question why the others haven’t implemented such functionality (yet)?
And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often.
Interesting. If I’m not mistaken, both Spacemacs and Doom Emacs offer similar functionality through the emacs-which-key package. I would think that Neovim should have some plugin that does something similar, but perhaps not.
Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).
I didn’t expect for them to be so many 😜. Hmm…, food for thought; thanks for pointing that out!
And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.
I definitely understand that Vim’s future is lot less certain compared to two years ago due to the passing of Bram Moolenaar. However, and I might be wrong on this, but I feel as if Vim has reached a critical mass of following such that it’ll probably continue to exist in some healthy form regardless.
In general I think you make a excellent case for Helix. I’m actually considering if I should reconsider it (if that makes sense). Uhmm…, but two questions remain:
- I shouldn’t expect remote accessing some random server will allow me to use Helix, right? Is there any other way to make this work? Or…, should I just learn both Vim and Helix’ Vim + Kakoune amalgamation?
- Vim is literally ubiquitous and plugins that enable its features can be found on almost any ‘platform’. It’s unrealistic to expect Helix’ adoption to be at that rate (yet). However, would you happen to know if at least the likes of VS Code and/or Jetbrains’ IDEs support it? And if so, how good their support/implementation is?
Which does beg the question why the others haven’t implemented such functionality (yet)?
Helix continues the work previously done by Kakoune (some people prefer Kakoune over Helix anyway). As to why - because it, like any other computer science topic, is a topic of active research, and Kakoune is the next generation of research into modal editing. Disclaimer: I use Neovim because it works well enough for me (it does offer more configurability, but I doubt I use it that much) and I don’t want to learn another set of hotkeys (which is similar enough, but still different).
I shouldn’t expect remote accessing some random server will allow me to use Helix, right?
That’s right, but as a Neovim user, it’s hard for me to use Vi, because it lacks many features, and I don’t know which ones. When you start going from basic to advanced knowledge, it sadly doesn’t translate. Of course, I would still pick Vi over Nano any day.
There’s a similar problem with many shells (fish, readline (bash)) that don’t fully implement Vim’s features, so their Vi mode sucks, but I still use it.
As to why - because it, like any other computer science topic, is a topic of active research, and Kakoune is the next generation of research into modal editing.
Interesting. First time I’m hearing this, but I’m very interested to learn about it. Thank you for mentioning this!
That’s right, but as a Neovim user, it’s hard for me to use Vi, because it lacks many features, and I don’t know which ones.
Very interesting. Did you first start with Vim or Neovim?
I shouldn’t expect remote accessing some random server will allow me to use Helix, right? Is there any other way to make this work? Or…, should I just learn both Vim and Helix’ Vim + Kakoune amalgamation?
That all depends on the server in question and if you can install things onto it or not. Some points to consider though:
- If the server is restrictive on what you can install then you likely are stuck with basic vim or worst only vi - and without all your configs it is a very different beast of an editor anyway and something you will need to get used to everytime you jump on the server.
- If you can install stuff to your home drive then it is quite easy to get helix running - it is a single binary with some language assets (requires one env var to point to them). So is trivial to get working from your home dir without a package manager.
- IMO you should not be editing things on a server often enough to worry too much about what editors it has on it. Ideally with things like ansible you should not need an editor on it at all.
Vim is literally ubiquitous and plugins that enable its features can be found on almost any ‘platform’. It’s unrealistic to expect Helix’ adoption to be at that rate (yet). However, would you happen to know if at least the likes of VS Code and/or Jetbrains’ IDEs support it? And if so, how good their support/implementation is?
Do you mean vi input mode in other editors? That is one downside - you wont find it anywhere yet. Though since learning it I have not needed to go back to other IDEs like VS Code or Jetbrains, WIth inbuilt LSP support its language integration is just as good as VS Codes as it is working off the same essential language servers. Though it does seem that at least vscode has a plugin for kakoune keybindings which are more similar to helixs.
Though what you will find is a lot of the keys are very similar between vi and helix, so apart from the big action > movement vs selection > action and a few other things they dont feel too dissimilar from each other (things like basic movement, ie w for word, e for end of word, or text objects are essentially the same).
and without all your configs it is a very different beast of an editor anyway and something you will need to get used to everytime you jump on the server.
Good point.
If you can install stuff to your home drive then it is quite easy to get helix running - it is a single binary with some language assets (requires one env var to point to them). So is trivial to get working from your home dir without a package manager.
I’m impressed. Thank you for pointing this out.
Ideally with things like ansible you should not need an editor on it at all.
Hmm…, honestly, I haven’t yet done a lot of things with Ansible yet. Perhaps it’s time to go explore that rabbit hole as well 🤣. Thank you (once more) for pointing this out!
Do you mean vi input mode in other editors?
Yes.
Your input has been much appreciated! Thank you!
