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.

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

- magit :: everyday things are just a key away, less common things are visible, complex things are possible

- Org-mode :: whole life in plain text (for some brain types it enables almost impossible to achieve otherwise + Org-Babel + emacs-jupyter

I can do things no other would let me do easily. Namely: create automatic exams with latex, each for a different address and send each to its corresponding pupil, all in a single script.

Attaching is a breeze, by the way.

Well, Ctrl-_ is three keys; control, shift and _. However, Undo in Emacs is actually designed to be on the two-key combination Ctrl-/ and the fact that this key produces the same ASCII control code as Ctrl-_ is incidental.

     (global-unset-key [(control z)])

But the nature of the editor is customization like this. People unwilling to do this just aren't ever going to be happy with emacs. And for those just learning, tricks like that (c.f. emacswiki.org) are a very reasonable entryway into a world of possibilities.

I mean, look, Emacs isn't ever going to be VSCode. If you want VSCode, use VSCode. It's a great editor, and frankly at this stage I think nothing is going to do VSCode better than VSCode already has. Emacs is something different, and we might as well embrace that.

(Not that I'd object to switching some of the dumb defaults around, of course. I just don't think that's going to help very much if your goal is "displace VSCode").

Shipping with some easily configurable presets to mimic other popular tools would probably help new users a lot.

    (when window-system
      (global-unset-key (kbd "C-z")))

  (when display-graphics-p
    (global-unset-key (kbd "C-z")))

Would I submit my choices as good defaults for new emacs users? Hell no. But they remain good choices nonetheless. That's the essence of my point, not the minutiae.

1) I don't have to worry about finding free bindings under C-x, C-c, or at the top level. Those spaces are pretty crowded with out-of-the-box bindings.

2) C-z C-h automatically gives me a nice list of my custom bindings.

(For the very rare times when I actually want to suspend Emacs in a terminal, I don't mind typing out M-x suspend-emacs RET.)

  (if window-system
      (global-set-key (kbd "C-z") 'undo))

Of course, no context switching is needed if you do everything in Emacs.

People trying to learn very deep kind of software should be ready to swallow a little more info than that IMO.

Out of genuinely interest, what claims specifically are you addressing here and why do you think are they wrong?

That Emacs lets you design a great user interface is exactly why some people want to “live in Emacs”. (Similar to how some misguided souls prefer to “live in the terminal”...)