It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin.

That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.

It's a slightly different philosophy. Emacs is best viewed not as text editor with plugins, but as a Lisp Machine emulator with a text editor. The joke about it being an OS is more true than people think: what you get is a (2D, not 1D like shell) text-oriented programming environment, back from the times where "a programming environment" meant a fully end-user-programmable OS.

This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).

VSCode philosophy feels more restrictive compared to that.

As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).

Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.

Keyboard conventions do come and go but muscle memory is expensive to reprogram. Your hands are also irreplaceable. So I go for the most efficient that's not too radically unfamiliar or painful.

And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.

I think you missed the point where they mentioned you can change any and all keybindings in Emacs.

Right but that requires learning Emacs well enough to change bindings. Then all the other tweaks one makes to a tool like text expansions, macros, and learning differences in find-replace, refactoring, and autocomplete.

There's no more learning required for changing Emacs keybindings than in other IDEs. If you don't want to go the scripting way, you can use the Customize interface, which is Emacs's equivalent of Settings dialog in most other software. Hell, unlike most software, Customize interface gives you a choice between applying changes temporarily and permanently, so you can try things out and if you mess up, just restart the editor.

(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)

Current keyboard conventions go back to 1984 and the Mac, and no sign of them changing anytime soon.

The article mentions Excel, for example, coming a few years after that and going strong today.

So I really do think Emacs predating those conventions is not going to be overcome.

The difference between VSCode and Emacs is the difference between an extensible text editor, and an editor that was designed to be extended, molded, and shaped as you work. At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality. What's more, the always-on presence of Lisp turns Emacs into a computing environment with strong editing primitives, rather than a text editor with stuff bolted onto it. I use it to automate tedious tasks, where it serves as a sort of Lisp-programmable super-shell that can ingest data from processes and network connections into buffers, as well as the inverse, all under the control of a powerful programming language.

I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp? You mentioned network connections - do you actually do scripting with Elisp's networking primitives?

I've long felt that this was an obvious and good use of Emacs - as a central coordination point for the entirety of one's computational life, with everything manipulated programmatically from a single programming environment with both rich UI capabilities and a full-fledged programming language. No other project seems to understand the value of such a central point... but still, there are many ways Elisp could improve to make this kind of usage easier.

> I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp?

No. But I do use Emacs Lisp to automate certain tasks and then wrap them up in an Emacs interface -- like highlighting some JSON to submit to an API endpoint, or using ivy to select a Docker container to start or stop.

> You mentioned network connections - do you actually do scripting with Elisp's networking primitives?

Emacs provides an OOTB way to hit API endpoints in the form of 'request'. So it's not just the networking primitives, but the utilities built on those primitives that Emacs comes with.

> there are many ways Elisp could improve to make this kind of usage easier.

Emacs Lisp has had two major warts: speed, and the lack of lexical scoping and CL-like constructs. The latter is largely addressed. The former is being worked on with efforts like gccemacs.

Question: how do you become most efficient in writing python?

Your answer: Learn Lisp!

Technically true even in spite of emacs, but if every engineer out there learns lisp to write better python wouldn't that be an interesting world.

Why? A good Lisp will give you a decent ride around the block. Even without reaching code-data-equivalence enlightment, it's a fast way to round your knowledge of various paradigms and approaches.

> At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality.

This is also true for VS Code (with JavaScript instead of Emacs Lisp of course). VS Code is just a bit more organized on the surface, giving it significant advantages over emacs in that regard, but also a bit more closed in culture.

I've recently switched from Spacemacs (vim-style modal editing and keyboard commands, in Emacs) to "Vanilla" Emacs.

I've been finding that once I changed capslock to become control, the various keyboard commands in Emacs make a lot of sense to me. In fact, far more than I thought they would, to the point where I'm feeling a lot more comfortable and competent performing the shortcuts, which means I remember a lot more of them. (Remembering shortcuts has always been a problem for me because I have various Adult ADHD issues.)

Sure, it's just one person's anecdotal and subjective, experience, but I've found myself using Emacs to edit my code (mostly Terraform and Ansible) much more than VSCode.