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 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.
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. It is a modal editor that is a mix between Neovim and Kakoune editors. It comes with batteries included, and supports an IDE like experience out the box with treesitter syntax highlighting and LSP language integrations out the box. My whole config is like 6 lines long yet it works far better then my old neovim setup with a multitude of plugins and hundreds of lines of config. It is like what AstroNvim, LazyVim, LunarVim and NvChad etc are trying to do to vim/neovim but instead has built in support for all the things they rely on plugins for. Which means there is no need to constantly keep them up to date nor weird edge cases where one plugin does quite integrate with another smoothly. It is all built in so things are designed to work well together.
But it currently does lack any plugin support. So if something is not built in that you want you have to make due without it (well, except language support, adding new LSPs is not too hard). And plugin support is being worked on so even this will be a non-issue hopefully in a year or two.
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.
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?
Did you first start with Vim or Neovim?
I probably started with Vim, but I honestly don’t see much reason to use it over Neovim besides better out of the box fbcon support
I probably started with Vim
Hehe, I assume it has been some time since you started this journey.
Thank you for your contributions to the conversation 😊!
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!
As you’ve touched upon it; Helix’ keybindings and ‘sentence-structures’ are different to those found on Vi(m).
Unless you really want vim bindings, try them out. At least Helix is based on the Kakoune editing model which is the editor I use, and I much prefer the way Kakoune works over vim, while still being close enough so that you can pick it up quickly if you already know vim and the other way around.
Unless you really want vim bindings
I kinda do for how ubiquitous Vim keybindings are.
try them out.
Regardless, I think I will try it out after I’m at least somewhat productive with Vim.
I much prefer the way Kakoune works over vim
I think preference is generally subjective. So you’re completely in your right to prefer Kakoune over Vim (and vice versa). Though, if possible, would you mind elaborating what you prefer exactly and why?
while still being close enough so that you can pick it up quickly if you already know vim and the other way around.
Doesn’t that disrupt muscle memory?
I kinda do for how ubiquitous Vim keybindings are.
Yeah, that’s a great reason to stick with it. It’s unfortunate that nothing really has Kakoune bindings other than Kakoune.
I think preference is generally subjective.
Of course, I know preference is subjective. That’s why I didn’t say “it’s better” :P Could very well be that vim works better for you.
The big reason I like them more is the concept of selections. Basically instead of a cursor you have a set of selections with start and end position (which could be the same position for a normal cursor), instead of having the object to delete as a parameter. For example, to delete two words it’s ‘d2w’ in vim, while it’s ’2wd’ in Kakoune. And after you type the ‘2w’, the selection shows what you’re about to delete, because it’s a separate command. It’s more useful when you’re operating on larger blocks of text, of course, or chain multiple commands together to create the selection you want. Sure, you can use visual mode in vim but it feels like an afterthought in a lot of ways.
I’ve already mentioned it but you can also have multiple selections at the same time, which I don’t think vim really does (I could be wrong though). This makes bulk operations really easy since they work exactly the same as operations on a single selection. For example, if you want to prepend let’s say “foo” to the next 10 lines, in Kakoune it would be ‘9CIfoo<esc>’ where C creates a selection one line under the current one, and I works the same as in vim. I believe you’d have to use macros for that in vim, something like ‘qqIfoo<esc>jq9@q’.
Those two are I think the main reasons I like Kakoune.
Doesn’t that disrupt muscle memory?
I haven’t really had problems with it, at least. Maybe because I’ve used vim for a long time before Kakoune. TBH I also don’t really use vim a lot anymore except on one remote machine that isn’t mine.
It’s unfortunate that nothing really has Kakoune bindings other than Kakoune.
That’s indeed very unfortunate…
And after you type the ‘2w’, the selection shows what you’re about to delete, because it’s a separate command.
That genuinely seems like very useful functionality. Thanks for pointing that out!
Sure, you can use visual mode in vim but it feels like an afterthought in a lot of ways.
Could you perhaps give some examples so that I can better understand/grasp why you feel that’s the case?
Those two are I think the main reasons I like Kakoune.
I haven’t really had problems with it, at least. Maybe because I’ve used vim for a long time before Kakoune. TBH I also don’t really use vim a lot anymore except on one remote machine that isn’t mine.
I am very grateful to you for sharing your experiences as a long time Vim user that currently prefers Kakoune over it. It has definitely impressed me and made me a lot more curious towards it. And I genuinely feel like I should think this over properly before I rashly commit to Vi(m). Thank you for raising such awareness!
Could you perhaps give some examples so that I can better understand/grasp why you feel that’s the case?
Hmm, one I guess is that it is not “permanent” and deactivates after one command (in Kakoune, you have to explicitly do ‘;’ to collapse the selection to its end (which you can flip with the start using ‘alt+;’) or move around without extending the selection). That’s really the only thing I can think of at the moment and I feel like often it really doesn’t matter tbh, so maybe I was just talking out of my ass there a bit lmao.
Apparently you can quickly reselect it in vim with ‘gv’ though, which I never checked until now. That’s useful to know.
One thing I’m really missing from vim though is that it can list directories, has a hex editor, and can read a bunch of other file formats. I think it can even edit remote files over sftp, but maybe I’m confusing that with Emacs. Kakoune just does local text files (though you can of course do stuff like ‘%|xxd’ to pipe the file through xxd to get a hex view, edit and then ‘%|xxd -r’ and save but that feels very very sketchy).
Hmm, one I guess is that it is not “permanent” and deactivates after one command (in Kakoune, you have to explicitly do ‘;’ to collapse the selection to its end (which you can flip with the start using ‘alt+;’) or move around without extending the selection). That’s really the only thing I can think of at the moment and I feel like often it really doesn’t matter tbh, so maybe I was just talking out of my ass there a bit lmao.
Regardless; thank you for mentioning this!
Apparently you can quickly reselect it in vim with ‘gv’ though, which I never checked until now. That’s useful to know.
Hehe, thanks for sharing that; might become useful soon 😅.
One thing I’m really missing from vim though is that it can list directories, has a hex editor, and can read a bunch of other file formats. I think it can even edit remote files over sftp, but maybe I’m confusing that with Emacs. Kakoune just does local text files (though you can of course do stuff like ‘%|xxd’ to pipe the file through xxd to get a hex view, edit and then ‘%|xxd -r’ and save but that feels very very sketchy).
Until yesterday I knew almost nothing about Kakoune. But I’ve since tried to do some reading; while there’s still a lot to uncover and/or explore, I feel as if it tries to offer a more focused experience (for better or worse).
deleted by creator
I’m sorry, which editor allows you to exit easily with escape colon q bang enter?
Uh huh. That’s what I thought.
Hi. I’ve briefly shared my experience with neo(vim) and emacs here. Going into all the details would require writing an encyclopedia because they’re both so vast topics. I think the main factor of choice would be to know if you prefer to build your own perfect tool with just what you need and expand as you go (i.e. neovim) or just have a do-it-all ready tool right out of the box (i.e. emacs). Both will require some coding and maintenance anyway. In that regards, I personaly found neovim to be easier and more reliable but mileage may vary based on your needs and preferences. After years using vim 20 years ago, I made a break. Then I used emacs for a year before eventually going back to neovim. I would certainly recommend it vs vim and I would suggest starting from scratch (no lazyvim or similar) so you clearly understand how things work. This will certainly be useful in the long run anyway and that’ll eventually save you time. Note that I’ve also tried welcome screens (startup) but really couldn’t justify its use so I removed it after few months.
Hi!
I’ve briefly shared my experience with neo(vim) and emacs here.
Thanks for sharing that! I’ve just read through it and it was a very interesting read. Would you mind elaborating upon the following statement?
“the lack of uniformity across plugins coding which sometimes created some conflicts”
I think the main factor of choice would be to know if you prefer to build your own perfect tool with just what you need and expand as you go (i.e. neovim) or just have a do-it-all ready tool right out of the box (i.e. emacs).
That is indeed something that concerns me regarding Emacs. Like being able to surf on the internet or using it as a email client isn’t quite what I expect out of my IDE 😅. I guess the extensibility should allow ‘minimal’ installations, but this is something I should read more into. Thanks for pointing that out!
My statement about the lack of uniformity was in regards to several issues I had with some plugins in emacs. Even my friend who codes his own plugins for emacs was of no help because 1) there is too many approaches and dependencies to write plugins, 2) there was no solution. Also, there are too many plugins to serve the same purpose and I found it difficult (compared to neovim) to figure out the difference between them. At least twice I also experienced conflicts between plugins. Finally, the level of customization was also less granular than what offers neovim. Again, I can see why emacs is appealing to some. It’s just not for me. As I like to say, the number of options available in the Linux world is one of the most beautiful things that makes this OS the only one you can tweak perfectly to any user’s needs and preference.
I would add that neovim and emacs both have a steep learning curve but I personaly found the level of support and core and plugins documentation for neovim more accessible, readable, and better organized.
I completely share your vision about what an IDE should be doing. I’m old school and adhere to the “do one thing but do it right” philosophy. Also, I hate relying on one tool for several needs because if anything goes wrong it has multiple impacts. As a side note, I use neomutt as my email client and you can nicely couple neovim to it to write your emails ;)
I appreciate your input. Thank you!
Also, there are too many plugins to serve the same purpose and I found it difficult (compared to neovim) to figure out the difference between them.
Interesting.
Finally, the level of customization was also less granular than what offers neovim.
Very interesting. I’d love to hear more about this. Could you elaborate?
I would add that neovim and emacs both have a steep learning curve but I personaly found the level of support and core and plugins documentation for neovim more accessible, readable, and better organized.
I wouldn’t be surprised if this is in part attributable to the fact that Emacs is both an older project and is generally-speaking a bigger and/or more capable piece of software.
I completely share your vision about what an IDE should be doing. I’m old school and adhere to the “do one thing but do it right” philosophy. Also, I hate relying on one tool for several needs because if anything goes wrong it has multiple impacts.
I’ve often heard Emacs users pose the argument that Emacs as an Elisp interpreter does just one thing. It’s just that this single thing allows the myriad of functionality it offers. So in that sense comparing it to a terminal/console seems more apt than comparing it to a text editor. I wonder what you think of that argument.
As a side note, I use neomutt as my email client and you can nicely couple neovim to it to write your emails ;)
Hehe, that’s cool! Currently I’m really happy with Thunderbird so I don’t expect to move away anytime soon, but I’ll keep it in mind.
I’ve often heard Emacs users pose the argument that Emacs as an Elisp interpreter does just one thing. It’s just that this single thing allows the myriad of functionality it offers. So in that sense comparing it to a terminal/console seems more apt than comparing it to a text editor. I wonder what you think of that argument.
I only used emacs for a year so I may be wrong but speaking only about how I used it and my current workflow I don’t see a difference. Looking at the usage (and not the code), my very first impression of emacs was that it’s acting as a terminal multiplexer which I was used to and so I liked this aspect. Anytime you need to do something that goes beyond the tasks of an IDE (calendar, email…) you switch window/panel (I’ve always been confused with the specific emacs terminology). That’s exactly what I’m doing with Tmux where I run neovim and call other apps with a single keybinding. Then I can freely switch from one to another, close one, recall it in the state I’ve closed it…
Again, this is related to the philosophies of emacs and neovim (i.e. do-it-all or do one thing). While neovim is “only” an IDE, emacs goes beyond, and for me this is not a negative criticism of either app. You build a tool with the coding language you need to implement some functionalities. In that sense, to compare apple to apple, emacs has to be compared to neovim coupled to a terminal multiplexer.Hehe, that’s cool! Currently I’m really happy with Thunderbird so I don’t expect to move away anytime soon, but I’ll keep it in mind.
I used Thunderbird as well and did the switch mainly to allow me to achieve the workflow described above. I do most of my tasks in the terminal. Neomutt would certainly be one additional layer of complexity in your transition to an IDE, unless you chose to use emacs for your emails. Actually configuring emacs as an email client or going with neomutt is pretty similar. But at the end - and this is an example of the higher level of granularity I mentioned earlier - neomutt is more customizable.
Talking about the level of customization of the IDE functionality only, the plugins I use offer more configuration options in neovim as well.Orgmode is also one (the?) big star player in emacs and neovim is trying to attract some users by developing a similar thing here or there but this is not something that would benefit to my workflow. This is maybe one of the reason why people choose emacs vs neovim and why I could quit emacs easily. Going back to the coding language, you can see that the use of lua opens new doors to the original vim. What I appreciate though is that you don’t have to implement any features if you don’t use them in neovim so I can keep my system limited to my needs. This is also seen as a bad thing by some when you start because emacs is capable of quite a lot with a fresh installation while neovim can barely open itself ;)
Overall we’re all sharing personal experience so no generalization should be extrapolated from single visions and I’m aware of my own bias and preference for singl- task, lightweight, fast tool.
I’m so grateful for the time it took you to write this down. Thank you so much for your contributions in this conversation! I’ve greatly enjoyed reading every one of your replies. While I am currently not in the state to make any promises related to sticking to Neovim in the long run. I do think that I’m at least very interested to explore its possibilities. Have a good one! Cheers!
It’s always difficult to find a good starting point but remember that you’re not married to your apps so you can easily switch from one to another and maybe come back later. Over the years, I’ve seen most of Linux users going that route because 1) it’s fun and you learn a little bit from each experience, 2) Linux users are generally curious, 3) some apps may be more suitable to your workflow at a given time but your workflow may change over time, 4) Linux offers us so many options so it’s like unleashing kids in a toys store, you want to try everything :)
Yup, I think you’ve hit the nail on its head. I’ve decided on using both and explore their possibilities and find how they can be best utilized for my workflow. Thank you for the excellent engagement!
I’m actually using nvim for rust development and it’s really fucking great but I’ve been using vi for like 25 years so for me the only issue was configuration, the editor is just natural for me. If you also have to learn the editor I don’t know what your experience will be.
As for configuring it for development I started with spacevim and managed with half the functionality normal IDE provides for quite some time. The experience was still good. About 6 months ago I set up nvim and now I have everything I need. I think setting up nvim for rust was as complicated as setting up spacevim. Spacevim provides way more out of the box but changing configuration is not easy at all.
I don’t worry about vim/nvim “schism”. The support is still great.
I would say just go with nvim, spend a week to set it up and don’t get too obsessive if small things don’t work. Enjoy the amazing responsiveness and great editor and you will figure out everything eventually. And if you have any questions just ask. I can share my config.
As for configuring it for development I started with spacevim and managed with half the functionality normal IDE provides for quite some time. The experience was still good. About 6 months ago I set up nvim and now I have everything I need. I think setting up nvim for rust was as complicated as setting up spacevim. Spacevim provides way more out of the box but changing configuration is not easy at all.
Would it be fair to assume that the switch from SpaceVim to Neovim was due to how difficult changing its configuration was to better suit your needs? Would you say this is SpaceVim’s fault? Or rather Vimscript is to be blamed?
I don’t worry about vim/nvim “schism”. The support is still great.
I also meant it in the sense that perhaps later down the line something else will come out to ‘replace’/‘improve’ upon Neovim. Until -in turn- that one is one day replaced as well and so on and so forth… Like, we’ve already gone from Vi -> Vim -> Neovim. While, on the other hand, Emacs still is Emacs. Thankfully, the modal editing part of Vim should persevere regardless; even if the name of the editor changes every so often.
I would say just go with nvim, spend a week to set it up and don’t get too obsessive if small things don’t work. Enjoy the amazing responsiveness and great editor and you will figure out everything eventually. And if you have any questions just ask. I can share my config.
Thank you for the encouragement! At this point, I intend to start with Vi(m) to get used to the core experience.
The problem with SpaceVim is that it offers a lot of toggles that are easy to switch but there are no examples for more ‘custom’ config and I struggled to figure it out. There’s a lot of examples and guides for nvim so it was easier. I don’t know, maybe it was just me but with SpaceVim I also didn’t really see what’s possible. With nvim I just found long lists of useful plugins that you can add one by one.
As for the future I don’t really worry that there will be next thing after neovim. I didn’t write any custom scripts for it, all I have is just plugins with mostly default settings. It would take me a day to switch to another tool witch is not a big issue.
I think starting with Vim is a good idea. You can easily add plugins one by one when you will see the need for them.
The problem with SpaceVim is that it offers a lot of toggles that are easy to switch but there are no examples for more ‘custom’ config and I struggled to figure it out. There’s a lot of examples and guides for nvim so it was easier. I don’t know, maybe it was just me but with SpaceVim I also didn’t really see what’s possible. With nvim I just found long lists of useful plugins that you can add one by one.
Makes a lot of sense. Documentation is indeed very important. Thank you so much for sharing your insights and experiences! Much appreciated!
Nvim is more optimised, while emacs is more extensible. Basically you can modify core parts of emacs while it runs. I tend to use both, depending on the situation, with a lighter nvim config. Sometimes the 3 second emacs startup time is annoying so I use vim then. I think its fine to try both.
Regarding emacs declining popularity, I think that in the long term it could be a problem, since most people don’t want to learn elisp just to configure their editor. Elisp is very powerful in emacs, but its design is very different to other languages, so as emacs contributors get older, it could possibly lead to less and less new contributors.
Idk about the vim distros, but I think Doom Emacs is easier for beginners to get into.
I tend to use both, depending on the situation, with a lighter nvim config. Sometimes the 3 second emacs startup time is annoying so I use vim then. I think its fine to try both.
Could you elaborate more upon your workflow? Like, in which situation do you prefer Emacs and when do you prefer Neovim? I get that the lighter option is preferred when you want to perform a quick edit or can’t be bothered with startup time. But I want to know it beyond that and -if possible- what led you to favor one over the other in each situation.
Regarding emacs declining popularity, I think that in the long term it could be a problem, since most people don’t want to learn elisp just to configure their editor. Elisp is very powerful in emacs, but its design is very different to other languages, so as emacs contributors get older, it could possibly lead to less and less new contributors.
How do you envision Emacs’ future? Would, at some moment in the future, some kind of compatibility layer of sorts be developed that lower the entrance barrier? To my knowledge, Emacs has -contrary to Vim- been more open to community development. So I don’t expect something like NeoVim to be developed for Emacs as there’s less need for it. But I don’t know how much they’d be willing to change Emacs for the sake of making it more attractive for new users.
Idk about the vim distros, but I think Doom Emacs is easier for beginners to get into.
Compared to Spacemacs I assume*. If so, would you mind elaborating?
I’m not using lsp in Neovim so if I need lsp I’ll just pull out emacs. If I’m already in the terminal I’ll usually pull out Neovim to edit a file, but if I’m writing like markdown or something that uses images I like the ability to display images inline in emacs. LaTeX is always something I do in emacs because there’s a built in pdf viewer in emacs and there’s built in spell check also. In the terminal in emacs, sometimes I open up Neovim to do a quick edit because of muscle memory from the terminal. One thing that’s really cool about Neovim is that you can embed it in other applications, so if I really have to use an ide that’s not emacs, I’ll just do that.
I don’t use Neovim for complex tasks, because personally I find it a bit hard to discover commands compared to emacs. The menubar in emacs is really useful for finding useful commands in different major and minor modes.
Yeah there’s a thing called EAF, which allows python and javascript to be embedded in emacs. It allows for more complex applications to be built in emacs, similar to VSCode. I’m not sure how difficult it is to make something with EAF, but I haven’t really seen any things written in it that aren’t in the EAF organization. I think the future could be EAF or maybe something like EAF to be able to leverage the power of the javascript ecosystem like how VSCode does for a lot of plugins. There have been some attempts to rewrite emacs in different languages, but emacs is too large, and you would lose the old ecosystem by doing that.
There’s a larger community around Doom Emacs, and Doom Emacs looks nicer. Honestly though it doesn’t matter that much which one you use since they are both pretty good.
I’m not using lsp in Neovim so if I need lsp I’ll just pull out emacs. If I’m already in the terminal I’ll usually pull out Neovim to edit a file, but if I’m writing like markdown or something that uses images I like the ability to display images inline in emacs. LaTeX is always something I do in emacs because there’s a built in pdf viewer in emacs and there’s built in spell check also. In the terminal in emacs, sometimes I open up Neovim to do a quick edit because of muscle memory from the terminal. One thing that’s really cool about Neovim is that you can embed it in other applications, so if I really have to use an ide that’s not emacs, I’ll just do that.
Wow, the insights! *Vehemently noting these down somewhere* Heck, I think you’ve cracked the code. Since I’ve created these posts, I became more and more aware of how great both Emacs and (Neo)Vim are. And while I was already flirting with the idea to perhaps use both, I think you’ve just completely obliterated any other option; which is a good thing. As such, I’m actually grasping for words that would somehow be able to properly convey the feelings of gratitude I currently experience. For whatever it’s worth; thank you from the bottom of my heart!
Yeah there’s a thing called EAF, which allows python and javascript to be embedded in emacs. It allows for more complex applications to be built in emacs, similar to VSCode. I’m not sure how difficult it is to make something with EAF, but I haven’t really seen any things written in it that aren’t in the EAF organization. I think the future could be EAF or maybe something like EAF to be able to leverage the power of the javascript ecosystem like how VSCode does for a lot of plugins. There have been some attempts to rewrite emacs in different languages, but emacs is too large, and you would lose the old ecosystem by doing that.
Once more; much appreciated!
There’s a larger community around Doom Emacs, and Doom Emacs looks nicer. Honestly though it doesn’t matter that much which one you use since they are both pretty good.
Yet again; I’m grateful! Have a good one! I wish you and your loved ones the best!
Sometimes the 3 second emacs startup time is annoying so I use vim then.
The way I get around this is by using emacs in daemon mode. So it only has a long startup if I’ve just rebooted my computer or if I needed to change my config and manually restart emacs. You probably already know emacs can run as a daemon, but I thought I’d mention it anyway!
For years I used vanilla vim before finally switching to spacemacs like 4 years ago. I’ve never used neovim, because it just didn’t seem stable and mature enough before I switched to spacemacs and at this point I’m happy with spacemacs and will probably stick with it for the foreseeable future.
My issue with vim, and the reason I switched, is that vimscript was an absolute nightmare. I was doing easy stuff, writing LaTeX, but getting vim to compile LaTeX and talk to my pdf reader (as you need if you’re going to be working with LaTeX in any kind of serious way) took way too much configuration and my setup would break fairly often as well. Spacemacs is significantly easier. I was shocked when I went from “I’ve never used spacemacs before” to “I’m comfortably writing LaTeX here” in about half an hour. My setup still breaks occasionally and sometimes it’s a bit difficult to figure out why and how to fix it, but it’s much easier than vim was, that’s for sure.
I also just like the emacs workflow. I like helm, I like being able to change how the editor works on the fly just by writing some elisp anywhere, I like how easy it is to access the documentation on functions, variables, keybindings, whatever else you might need. I like org-mode. I like that emacs has been around for decades and will be around for decades more.
I’d never heard of doomemacs. I’m pretty happy with spacemacs so I probably won’t switch, but I’ll at least read about it some more.
Ironic that your main complaint about vim would have been solved by switching to Neovim – the weaknesses of vimscript are one of the main reasons Neovim was created, I believe, and it supports Lua as an alternate config language.
I was shocked when I went from “I’ve never used spacemacs before” to “I’m comfortably writing LaTeX here” in about half an hour.
This line really piqued my interest, especially considering that I’ve had another conversation with someone else in which the general sentiment seemed to be that “Spacemacs expects you to know Emacs, while being a completely different beast of itself.”. May I ask how your Spacemacs is configured? Would you say it’s close to the default config? Or rather a significant departure? Furthermore, I believe I’ve read the existence of some kind of version control. Which, at least by the name of it, should somehow contribute to a more stable experience. Or am I perhaps confusing things?
My setup still breaks occasionally and sometimes it’s a bit difficult to figure out why and how to fix it
Does this happen randomly? Or rather as a ‘response’?
I like being able to change how the editor works on the fly just by writing some elisp anywhere
This sounds very interesting and promising. Would you mind providing an example of sorts such that I can perhaps better grasp both the sheer amount of new possibilities it provides as well as its (possible) limitations (if at all)?
I like that emacs has been around for decades and will be around for decades more.
I wholeheartedly agree! But, I am at least somewhat concerned when it comes to its ‘gravitational pull from afar’. To me at least, it seems as if, currently, Neovim does a better job at attracting new people. Perhaps these are just mostly refugees from Vim. Nonetheless, it can’t be ignored (I think). Would you mind sharing your thoughts on this?
Disclaimer: Never really used Emacs, but mediocre VI(M) user for nearly 25 years.
I am fully capable of using VIM for developing bigger programs, but I gave up on the wish of setting up VIM as an IDE. Still, IMHO VIM is worth knowing for quick edits, writing and remote work.
Seriously, if you want an IDE for Python and C#, VS Code with the Microsoft plugins is and will be miles ahead of the VIM experience. The Rust plugin for VS Code is IMHO subpar, the last time I tried it. I don’t know what is the favorite IDE of Rust developers.
I wouldn’t want to stop you trying out editors and having a nice journey, but in the last years, VS Code ‘won’ and is used by nearly every developer for a reason: It has not a perfect setup and a lot of annoying issues, but out of the box the experience is good enough™ and is has the biggest user base by far, so show stoppers will be fixed quite fast.
So, my advice would be: Learn vi, because it is a handy tool for quick edits with good defaults (looking at EMACS) and chose a popular editor or IDE for your development needs. The time trying to force VIM/EMACS into a descent IDE will never come back and the theory sounds better than it will be in reality.
Do you have any experience with neovim? I’m certainly not a Python programmer but I’m doing simple things for fun and so far neovim served me very well. If I eventually go deeper in Python I would be interested to know the limitations of neovim beforehand.
No, never touched neovim.
The things you get ‘for free’ with VS Code:
- Integrated debugger
- Integrated unit test runner
- black
- isort
- linting
For Python, AFAIK Microsoft have their own implementation of a language server, so I don’t know how it compares to the Open Source options. My VIM config for Python runs black/isort on save and that’s good enough for me.
IMHO the distance is far greater when you use a language like Java/C#, which has really descent support from IDEs.
If neovim serves your needs, enjoy using it and don’t listen to random people in the internet. ;-)
Thanks for the information. I’m always happy to hear from others because that’s how I make progress. Also with my workflow in constant evolution it’s good to know neovim’s limitations so I can be prepared. Being curious by nature I will try other apps with no doubts anyway. I’ve tried vi, neovim, emacs, but only heard of VS so who knows…
Seriously, if you want an IDE for Python and C#, VS Code with the Microsoft plugins is and will be miles ahead of the VIM experience.
Someone else already pointed how VS Code has become the most popular IDE (at least according to statistics found on stackoverflow). While categorically I’d like to dismiss VS Code for not adhering to F(L)OSS, VSCodium -however- actually does fit the bill. And while formerly I’ve had bad experiences on it related to how the plugin ecosystem is configured by default compared to VS Code, I’ve since learned how it works on VSCodium. So I shall set it up in case Emacs and/or (Neo)Vim somehow seem to be less fit for the job and/or I can’t be bothered at that moment to configure Emacs/(Neo)Vim to do my bidding.
Learn vi
Will do.
The time trying to force VIM/EMACS into a descent IDE will never come back and the theory sounds better than it will be in reality.
I understand the concerns. And I agree that I should be realistic in how I approach this. Nonetheless, I’m faithful for it to be a very productive endeavor. Thank you for chiming in!
My pleasure. :-)
My impression about VS Code being popular is also from workplaces at several companies, VS Code was literally on every machine and VS Code project config files are nowadays checked in with project into version control. (In the past I would not have been happy about config files in version control, but I just accepted it by now.)
One more question: How to setup VIM/NEOVIM or EMACS as a descent C# IDE? AFAIK the language servers support navigation and auto completion, what about refactoring, code generation, support for build systems, hot reloading for code while debugging etc.?
My impression about VS Code being popular is also from workplaces at several companies, VS Code was literally on every machine and VS Code project config files are nowadays checked in with project into version control. (In the past I would not have been happy about config files in version control, but I just accepted it by now.)
That’s actually kinda concerning 😅. I hope I can remain free to use whichever IDE suits me best. But thanks for pointing that out as it’s a very realistic scenario.
How to setup VIM/NEOVIM or EMACS as a descent C# IDE?
Hehe, the crux. Honestly, I’m not very optimistic that it can do everything one might be used to do on something like Jetbrains’ Rider. Nonetheless, I’ll try to get it as close as I can and see from there if I’m willing to deal with it. I’m not entirely opposed to rely on other IDEs from time to time for specific functionality I’d be missing otherwise.
I tried several editors but always come back to emacs. When I used LaTeX because of AucTeX, then I discovered org-mode and now I do my writing with org-mode and ConTeXt.
I tried several editors but always come back to emacs.
Have you used Helix and/or (Neo)Vim? If so, would you be so kind to share your experiences?
I use Emacs + spacemacs in VI mode as a base for all my text editing on both Linux and windows (which is unfortunately required for work on occasion) machines.
For dev environments I mostly use nix + direnv + direnv-mode.
For C# I use the above plus omnisharp-roslyn + lsp-mode.
I tinker in all sorts of languages, and they all have at least basic support in the Emacs ecosystem. The popular ones should have fully functional language servers and debugger adapters.
I use Emacs + spacemacs in VI mode as a base for all my text editing
Do you specifically prefer using Spacemacs as a base over Doom Emacs? Or is the usage of Spacemacs primarily attributable to it coming earlier to the scene?
Furthermore, as you’re using it in “VI mode”, would it be fair to assume that you’ve got some experience/history with Neo(Vim) as well? If so, what led you to making the switch from (Neo)Vim to Emacs?
For dev environments I mostly use nix + direnv + direnv-mode.
Very interesting! Relying on Nix rather than Distrobox has been something I’ve been pondering upon. But besides the fact that I’m still very new to Nix as an ecosystem, I’ve also got my concerns related to what degree the containers can be sandboxed. Do you happen to have some insights on this?
Or is the usage of Spacemacs primarily attributable to it coming earlier to the scene?
Yeah, pretty much just that. If was to start again now I’d consider other options, but I have no serious complaints about spacemacs. I probably would have never got into Emacs at all if I had to start with vanilla.
Furthermore, as you’re using it in “VI mode”, would it be fair to assume that you’ve got some experience/history with Neo(Vim) as well? If so, what led you to making the switch from (Neo)Vim to Emacs?
Yeah, I used VIM (and I still do when I’m in an unfamiliar environment), but only before neovim existed. IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.
I’ve also got my concerns related to what degree the containers can be sandboxed. Do you happen to have some insights on this?
What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have
OmniSharpordotnetin my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to startOmniSharpas a language server, or I can rundotnet buildusing the Emacscompilecommand.You can define containers with nix and manage them with
nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.I probably would have never got into Emacs at all if I had to start with vanilla.
Very interesting. I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?
IMO Lisp is what makes Emacs great, and vimscript is (was?) an absolute nightmare for anything complex. I don’t think lua is a bad language, but I’ll still take Lisp any day for this purpose.
This is actually a great point that I somehow completely ignored so far. I intend to put my teeth in GNU Guix at some point in the future. As Guile Scheme and Lisp are -to my knowledge- at least in some way related, using Emacs should at least provide an excellent platform for me to get accustomed to what it is yet to come. Thanks for mentioning that!
What I described isn’t using containers. Nix just provides an environment for processes to run in, and direnv-mode ensures it’s using the right environment for a given buffer in Emacs. So for example I don’t have
OmniSharpordotnetin my user $PATH, but they are provided by the nix expression in a particular project directory. That allows lsp-mode to startOmniSharpas a language server, or I can rundotnet buildusing the Emacscompilecommand.That sounds very compelling! Thanks for that insight! Perhaps I should stop procrastinating and get on with learning Nix 😅.
You can define containers with nix and manage them with
nixos-container. I do that for testing server deployments, or running sandboxed services, but I’ve never needed something that complex for a dev shell.Yet another reason in support of learning Nix.
I assume this is due to the amount of effort that would have been required for it to acquire some of the functionality you were expecting out of it. Am I right?
I didn’t really understand what Emacs was at the time, I just got fed up with trying to make vim into an IDE. Out of the box, spacemacs had good language support, modal editing, and looked ‘modern’.
What I love about Emacs now is Lisp and the package ecosystem. I have 396 packages installed, and many of them interact in quite complex ways. When I do a package upgrade it pretty much pulls the latest from the development branch of each package. Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.
I intend to put my teeth in GNU Guix at some point in the future.
Me too, but I nix has served me well, so I haven’t been motivated.
Thank you so much for your insights! Much appreciated!
Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.
I want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.
I want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.
Not that much really. I usually upgrade everything once a month or so. The last couple of times were smooth. I think the last problem I hit was:
https://github.com/emacs-lsp/lsp-mode/issues/4153
This was actually triggered by upgrading omnisharp, which started sending a new notification that lsp-mode didn’t explicitly ignore.
By the time I hit it, that issue had already been reported, so I was able to quickly work around it with a snippet in my main config. I could have also just rolled back omnisharp.
Most problems I’ve had have been solved by upgrading spacemacs to latest.
Honestly, that’s very encouraging! Thank you so much for providing me with very valuable insights and information! Have a good one! Cheers!
I’m a bit surprised that no-one mentioned ALE. If you want to turn vim into an IDE it goes a long way.
Having the compiler warnings/errors inside the buffer is already really useful, but then you can also add LSPs and there isn’t really much missing. I’ve recently developed a Java program entirely in vim using Eclipse’s LSP.
I’m a bit surprised that no-one mentioned ALE. If you want to turn vim into an IDE it goes a long way.
That’s very useful! Thank you for mentioning that!
I’ve recently developed a Java program entirely in vim using Eclipse’s LSP.
Very interesting! I’d assume one would have to be relatively fluent in Vimscript to pull that off. Would you mind sharing your thoughts regarding Vimscript? I especially feel the need to ask as a lot of other users so far have been championing Neovim with some of them being particularly vocal regarding their dislike towards Vimscript. And would you also be so kind to share your thoughts regarding Neovim?
have to be relatively fluent in Vimscript to pull that off
I don’t think so, using ALE just requires to install the plugin and the external programs that it will interrogate. I know almost nothing about Vimscript.
thoughts regarding Vimscript
From what I’ve seen it’s a scripting language like any other, but one that is extremely specific to vim. The syntax is also quite different from anything else, so I never felt the need to learn it.
Neovim
As a general concept, it seems a good idea, I also know Lua so it would seem to be a logical switch for me.
However, during these years every time I tried it it had some slight differences from vim that made using it somewhat annoying. Moreover, it never seemed to provide such a better experience that made me switch permanently. I’d like to like it, but I never had a reason to.
I know almost nothing about Vimscript.
This is actually good news as it means I shouldn’t have to learn a new language to engage with it.
However, during these years every time I tried it it had some slight differences from vim that made using it somewhat annoying.
Interesting. Would you mind elaborating upon those differences?
Honestly, I don’t even remember. It was something to do with minor differences in the cursor movements of specific commands.
Anyway, it’s been years, anything may have changed in the meantime. I should probably give it another go, those were simple nitpicks that I was too impatient to tolerate.
Thank you for sharing your thoughts and experiences. Cheers, mate.
As a long-time Vi user I would highly recommend giving it a shot for a solid month to see if it clicks for you. It’s genuinely an excellent way to edit text beyond “just typing words” - it’s a huge productivity boost once you’re competent with even some of the basic commands. There are just soo many combineable short-cuts at your fingertips that once you get a few of them under your belt you’ll go nuts without them. And the simple macros you can write can allow you to do mass manipulation of multiple lines in ways that are just so simple (e.g. “add quotes around every line and a comma at the end”).
Dive in beyond the basic “hjkl:q” though.
Which version of vi you use won’t largely matter. As a bonus most IDEs support a good subset of vi commands so your skills become transferable. I use PyCharm and other Jet Brains IDEs all the time and ideavim is “good enough” for what I do.
Emacs is dead near as I can tell.
Dive in beyond the basic “hjkl:q” though.
This is a video I can’t recommend enough: https://www.youtube.com/watch?v=d8XtNXutVto It’s long (>1h) but it’s very well made.
It’s a long tutor go through with some bonus advanced tweak, and the explanations clearly helps remembering everything easily. If I knew it when I’ve started that would have saved me so much time and helped me from getting into bad habits I then had to fight against.
As a long-time Vi user I would highly recommend giving it a shot for a solid month to see if it clicks for you.
Makes sense. Thanks for the tip!
Emacs is dead near as I can tell.
Am I correct to assume that you think that Emacs is dying? If so, would you be so kind to elaborate on why you think that’s the case?
My comment on Emacs is a bit flip - but it’s based on what I’ve seen and from my biased vi-using POV. Almost every IDE or developer-focused app I use has some sort of Vi keybinding either available as a plugin or built-in. And they’re often pretty good. Even joplin which is a note-taking app has Vi keybindings built in (though to be fair it also supports emacs keybinds).
If anything Vi keybindings have become more popular over time not less. “back in the day” getting any sort of Vi keybindings working with IDEs was either impossible or painful and limited. These days it’s a checkbox. The nice thing is I can take a good sub-set of the Vi bindings between many editors and IDEs. Ideavim’s implementation is quite good and even supports vim macros which are amazing once you get the hang of them.
Emacs keybindings are in the terminal and are in MacOS (from what I’ve heard online).
This is true. The ctrl+a, ctrl+e and ctrl+l stuff is very emacs-like.
You can actually set bash to use a vi mode as well (set -o vi). Though I’ve found it to be annoying for use on the CLI for some reason.
Ah okay. It has become a lot more clear what you meant. And I agree; implementation for Vi(m) keybindings is ubiquitous while the same can’t be said for Emacs’. But, while Vi(m)‘s keybindings define a lot of what it is and why people love to use it, the same simply can’t be said for Emacs’ keybindings. I’m sure there’s someone out there that absolutely loves it, but it doesn’t come close to how Emacs’ modeless nature allows almost limitless extensibility or how ‘smart’, ‘useful’ and just plain excellent its org-mode is.
Vi (and other mode-switch vietnam-era editors with cult like followings of which there are none) really impaired my first few weeks of comp sci until a t-a showed me there are options. Modal editors were neat when required, but then we got full keyboards and control keys.
Man, does vi suck, but its thuggy PR volunteers do a good job of keeping people from assessing alternatives.
I’m glad there were options.
Modal editors were neat when required, but then we got full keyboards and control keys.
Have you ever seen old Unix keyboards?
How long did you try using Vi (or any other “mode-switch vietnam-era editors with cult like followings”)? Have you experimented with any starter kit/distribution/config (or whatever) to ease you in? What do you use now?
Btw, I agree that stand-alone Vi probably is too far of a departure from modern IDEs. As far as I know, it’s not even possible to give it IDE-like functionality apart from a few basic ones. Both Vim and especially Neovim do a better job at bridging the distance. FWIW, Vim only exists like for three decades now, while Neovim’s first release happened in 2014; almost 10 years ago.
