I haven't personally used VS Code much, but from what I understand, it still runs in two castes that don't, generally, mix: there's its core code, and then there's plugins, and the latter exists on a separate plane from the former. You can't write a plugin that redefines some core behaviour. The functions internal to the core are not all automatically accessible for any plugin. Plugins don't become fully integrated with the core code to the point where the source file location is your only hint as to whether behaviour comes from a plugin or core functionality.

(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!

Yeah, exactly. For example, evil-mode is still miles better than VSCode Vim plugins just because it works everywhere. Any buffer that my Emacs opens I can still use my Vim shortcuts (so it doesn't change that I open a text, a binary, file manager, a fuzzy search or PDF). Compared to this, on VSCode I basically need to explicitly say "make vim commands do this in this context" for everything I need.

My current client wants all of us to standardize on VS Code at some point, and this is by far the most annoying thing for me. I hate that if I leave the editor, it goes back to a mouse-driven design. I'm glad to hear you can change the behavior, so I guess I'll just have to do that at some point to make it work for my needs.

This is the main reason I changed and do most of my work in Emacs, keyboard only. Using it in terminal is a bit of a bonus. Onivim2 seems promising in bridging the gap, but we'll see.

No, I do not go "Emacs plugins can do what now". I rather go, "and that is supposed to be a good idea?". If you want to use Emacs as an OS, doesn't protected mode seem like a desirable feature?

From personal experience, I've benefited way more from that than I've been hurt by it. Whether that's true for all people I don't know.

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!

Unless I was very unlucky in my decisions about what and how to learn about vscode or my ability to learn has dropped more than 10-fold between the time I learned to modify Emacs and the time I tried to learned to modify vscode (which is unlikely but not impossible: it was an interval of 28 years) emacs is much easier to learn to modify than vscode is unless one is already a web dev.

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.

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?

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.

I'm doing a highly integrated language environment for a research language and faced this decision recently.

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.

> VSCode presents an API around a specific notion of what a language is and how it interacts with the editor

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".

yes - but those are completely optional

That is true of any editor: they will only seeem intelligent if you ask them about the languages they have support for.

By its nature software designers have to make some decisions on what should be easy, what should be possible and what you'd be better off using some other app for.

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.

Emacs is not that much different there with it's C-core and lisp-land. It had even a similar case with the reimplementation of linenumber-mode in C for performance-reasons. The question is more what emacs can offer generally that vscode is lacking in ability, even just theoretically. Because in reality there are of course many features not implemented yet in vscode.

> If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?

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.

> 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.

Let's face it, the fact it's free software is the reason it's used at all, the reason it's been hacked on by so many people, etc... It's always relevant to discuss it's free nature, especially when discussing it's popularity.

Ah, but Javascript is a profoundly terrible language to do anything in, while Lisp is a joy to write in.

Being a Lisp machine is core to the value of Emacs. Emacs-without-Lisp is just another editor.

eLisp? Where lexical scoping is this brand new feature that generates compiler warnings? Where the UI thread is the same as your eLisp thread? Where multiprocessing is a super clunky fork-exec with a weird side buffer? Where a simple regular expression works differently between what the user invokes and how you'd write it in a function?

Yeah, it's a super joy to write.

As someone who uses Emacs and likes writing lisp, 100% agree. elisp is without a doubt the worst lisp still in common use.

It is a joy. When writing code in the ivory tower :-)

Elisp arguably has worse warts than Javascript. For example, non of Javascript's legacy 'var' scoping nonsense compares to elisp's archaic model of using dynamic scope for everything by default. On top of that, modern Javascript implementations are of extremely high quality, whereas Elisp is stuck with an interpreter of mediocre performance.

> Javascript is a profoundly terrible language to do anything in

Makes it really hard to take anything you say seriously when you reveal just how ok with extreme hyperbole you are

What do you find profoundly terrible about JavaScript?

I disagree, I like JavaScript

Not exactly, VSCode is more of an editor that can accept very advanced plugins. The "virtual JavaScript machine with a standard library for writing graphical (text) applications." is a web browser.

I have not played with VS Code a lot, but I get the impression that, yes, they aim for something similar. I'm not qualified to judge, though, how successful they are so far.

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.

Isn't the Guile effort practically dead? I remember hearing about it 10 years ago.

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? :-)

I honestly don't know about the state or progress of Guile Emacs. I know it exists, but I haven't followed it beyond that.

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?

Yes, Guile Emacs got abandoned, at least the last time I checked.

Is that like what the GCC-emacs project is doing with libgccjit? They are working (and have a great start on it) version of compiling most (all?) elisp with libgccjit to speed things up a bit if I understand it correctly. I have compiled it myself and it is most certainly faster to load and do "intensive" tasks faster than stock emacs. I've loaded both DoomEmacs and SpaceEmacs successfully with it.