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:
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(TM) 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.
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 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.