As an Emacs user I'm mostly "afraid" of VSCode getting so popular that people will make cool tools targeting VSCode only. Like, it'll become the Chrome of text editors.
Editor trends seem to fairly volatile. Textmate was the new shiny favorite until it wasn't. Sublime was the new shiny favorite till it wasn't. Atom was the new shiny favorite... etc.
Those had all legit flaws which prevents wider usage, like being limited to one platform, being commercial or slow or dead... They all lakc in concept, because they are editors first, and not much of an IDE. VS Code is the first who actually avoids all the flaws. It's flexible, yet still quite fast, relative tame on RAM, yet full of IDE-features, running on all platforms and cost you just some privacy if you don't know about the data-collecting.
Additionally, it sparked the LSP a movement which is benefitial for all editors/IDEs, and we will see how much more will come from this. So even if VS Code itself will lost traction, it's heritage might prevail. But overall the specs so far look very healthy for a project in that realm, and chances are good that it will stay for a while.
Emacs hasn't been really mainstream in quite a while and it's still actively maintained and improved upon. I'm not too worried. A small-ish skilled community is enough to keep the project going.
What's VSCode's market share anyway? Is it really that big? I've never used it personally and I had no idea it was so popular.
> A small-ish skilled community is enough to keep the project going.
The trends of the last few years are worrisome, though, particularly as regards the pool of developers who can work on Emacs core (the part written in C). Right now there's only one dev who's in a position to do non-trivial work on the display engine, and he also took on primary maintainer responsibilities a couple of years ago. When he burns out, the project is going to stall, hard.
Stefan Monnier, who was maintainer for most of the past decade, perceived this trend very clearly and was vocal in trying to recruit new talent. He didn't get much cooperation from other core devs.
It feels like Emacs Developers are actively tries to shoo away modernization and people who do not want to put in hours trying to actively learn just Emacs.
At one point I tried using Emacs for everything but it didn't work out for me. Now I still use it but only for tasks management and coding.
Unless you want to spend hours of your time customizing it and then a lot of other person also does the same customization. This just ends up wasting a lot of time overall.
For me Emacs lacks the following and I think others will have the same feeling:
Obscure Terminology
Documentation is all geeky with terms like frames, META, kill ring etc. This creates unnecessary friction for a new user. Basics of ELISP can be learned rather quickly but trying to apply it while grokking the tersely written documentation is just discouraging.
Sensible Defaults
Simple things CTRL-C, CTRL-V does not work out of the box.
Mobile Interface
It is an error not to provide a facility to interface with mobile devices natively. I get full Emacs can be invoked via termux on any Android device. However, it is just unusable and irritating. Orgazly and likes also not very useful.
Well the problem is that people caring about Emacs have learned a long time ago what a kill-ring, the point, the cursor and meta mean in the context of Emacs. In its defence, a lot of that predates modern user interface conventions. Changing this lingo would probably make it more approachable for newcomers but it would confuse experienced users. On top of that you can be sure that not all elisp out there will be updated quickly (if ever) and you end up with two different words for the same things in different docs which is not exactly a win for anybody.
Beyond that Emacs's docs are unparalleled in the editor world as far as I know, you can explore pretty much any functionality by calling "describe-key", "describe-mode" etc... Even decades later very few (if any) editor can rival the flexibility and self-documenting nature of Emacs.
Regarding key bindings I agree that it's definitely a pain point for newcommers, it's just too different from the modern standard (while not necessarily being better. C-_ for undo? I got used to it but it's hard to defend). Unfortunately making a complete new set of bindings that would play nice with 3rd party packages is probably very difficult.
> Well the problem is that people caring about Emacs have learned a long time ago what a kill-ring, the point, the cursor and meta mean in the context of Emacs.
Those people are not going to live forever so if Emacs wants to have fresh blood inducted then a gradual modernization would not hurt. I think even Richard Stallman agrees[1] to some of it.
> Beyond that Emacs's docs are unparalleled in the editor world as far as I know, ....
I agree Emacs have documentation for almost everything but I disagree on the quality of documentation. For example when I pull out a documentation Most of the documentation describes what the argument should be which is anyways clear by looking at the argument list. It would be much better to include an example instead of describing the arguments verbatim.
It's just my impression, but for the new generation of developers "born" into a js-first world it's pretty much the primary choice. And again I don't have numbers but it does seem like the new generation is MUUCH larger and much more active on mainstream social media.
Hacker news must seem like what slashdot seems to me.
I can see a situation where 0 users switch to VSCode and in a few years it still has, say, 80% of market share, just by getting all the new ones.
> And again I don't have numbers but it does seem like the new generation is MUUCH larger and much more active on mainstream social media. Hacker news must seem like what slashdot seems to me.
Part of it can be attributed to growth. If the population of programmers grows by 100% every 5 years (an estimate I remember reading somewhere), then at any given time, half of the workforce has at most 5 years of experience. This explains why our industry seems to be so full of "js-first" developers - because in fact, it is.
