... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more.
What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other.
I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.
I cannot blame you. And if vi makes you happy, I want you to enjoy the heck out of it. Between discovering emacs and making it my editor of choice I spent a few years using vi heavily, and to this day, I reflexively use it for quickly editing config files.
Regarding emacs, all I can say is that, in my experience, it gets better if you really stick with it for a while. The payoff is huge if you put in the time. But time is limited resource, vi gives you a payoff much faster, so ... like I said, if it works you, don't fix what ain't broken.
I love Emacs, but I also love the variety of editors programmers can choose from. With programmers' editors, as with society as a whole, I consider diversity an advantage.
My impression -- obviously as an outsider! -- is that Emacs' immense flexibility comes at the cost of providing a lot more surface area for packages to get in one another's way. When that happens, you need to be willing and able to untangle things -- and while each individual tangle is rarely a big ask, they can add up, especially when you're coming from VSCode or Sublime Text or what have you.
If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?
So now there's a product that leverages the architectural advantages of Emacs, with modern defaults across the board.
(A non-Emacs user might very well go "Emacs plugins can do what now?" at the description of a plugin re-defining a core function. That's a fully understandable reaction. That level of hackability is not for everyone. But as far as I can tell, it's unique to Emacs and very small set of other software.)
But I could be misunderstanding this. Maybe VS Code actually does have Emacs-level hackability, in which case I'd probably want to try it out more than I have!
Of course, you're not supposed to do it other than very carefully and it has caused me problems when some plugin has made a mistake in a way that worked for the original author but not for me, but because of the openness of the system, it's fairly easy to "overwrite it back" automatically when the plugin is loaded – and submit a patch back upstream.
So maybe this sort of system works only when a large portion of the users are hackers, and making Emacs more popular is not a good idea!
Of course, if one does learn how to modify vscode, one has a skill (namely, web dev) in much higher demand on the labor market than knowledge of Emacs Lisp.
Almost, but not quite. VSC doesn't give you javascript access to the internals of the application, it just provides a fairly broad set of extension APIs. You can see this in how the VSC equivalent of rainbow-delimiters-mode (parentheses and brackets recolored based on their nesting depth) had to be rewritten as part of the core application for performance reasons. This wasn't necessary for emacs.
elisp and javascript are both pretty iffy lisps, but at this point I think I'd prefer javascript.
however VSCode presents an API around a specific notion of what a language is and how it interacts with the editor. emacs comes in at lower level and presents a model with just buffers and text.
I remember elisp debugging as being a joy - not really finding that to be true. but I really don't want to be limited by what the VSC designers thought I should want to do with source files - actually I don't want to use source files at all.
I would say Emacs has this as well, in its syntax tables. They are its schema for "what a language can be" and especially "how the editor can interact with it".
If you're on something as radical as not using source code to describe a program (what are you using then? A DB of some sort?), I don't think either emacs or vscode can be your tool of choice.
We know there's no free lunch, if an extensible development environment was flexible enough to make this sort of thing easier, something else had to be made harder.
For the most part, except for the fact VSCode is owned by MS and has just enough proprietary code to break a lot of functionality if you try to use it without the proprietary bits.
That's a personal policy choice, not a technical concern.
Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.
Yeah, it's a super joy to write.
Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are
FWIW, when I hear people talk about VS Code, they appear to like it very much. But AFAICT, it has some way to go to catch up with all the functionality emacs has accreted over 30+ years.
Also, there is an effort replace the old lisp engine inside emacs with GNU Guile, which is a JIT compiler that supports Scheme, ELisp, and Javascript. I have not tried it so far, but it might become possible to customize and extend emacs with Javascript in the not-so-distant future.
It was actually started in 2000 and doesn't seem to have progressed since 2014: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht...
Plus, even if it's finished, will it get any traction in the ecosystem? Will the ecosystem start moving to it to take advantage of its unique benefits? Who knows?
Bonus: Have you heard of GNU Hurd? :-)
Assuming it gets "finished" (is any software ever finished?), it should be no-brainer as long as it provides backward compatibility with old elisp code. And open up the emacs ecosystem to Scheme and Javascript, which could make it much more attractive to newcomers. But, as they say, I'll believe it when I see it.
The trouble with Hurd, IMHO, is that I've run out of jokes. We used to joke that it would run Duke Nukem Forever out of the box, but that one actually got finished. Then it was Perl 6, but that has arrived, too. Star Citizen maybe?
Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general).
But this was about its popularity relative to other editors, not relative to other scriptable framework things.
Well then in that case, ship a better Lisp than emacs lisp?
What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.
It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example).
But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.