Hacker News Reader

> Emacs was invented for a world where Text was everything.

Text is still a large part of computing.

> These days programming languages are designed around tooling.

Every time I see a language which requires a lot of tooling to use it comfortably, usually it's bad designed one

> The whole idea of one having to press less buttons to move text around is really a solution for a problem that doesn't exist in the modern world.

I think the idea is not about having to press fewer buttons, but to bother your brain with unnecessary things as little as possible. With Emacs, you don't have to remember "where the hell is this command and what is the shortcut for it?", you type M-x (especially if you use plugins like counsel or helm) type some related words and that's it. You don't have to know how every function works - M-x decribe-function at your service! Not enough? You can always jump to definition and take a look at it.

> The thing is that kind of text manipulation work isn't common anymore.

You still write programs in text, the commands you give to computer ARE text too, even "modern" menus are nothing but text.

> The thing is that kind of text manipulation work isn't common anymore.

Emacs has LSP plugins, if that's what you are talking about

> Or in general some emacs features ported to vscode would be really neat.

Which features does VS Code have but Emacs don't?

> Emacs was invented for a world where Text was everything.

Given that you're still on a computer, what do you think isn't representable as text in one way or other? You can drag and drop images from a browser into Emacs[1], and it will download the image to a sensible (and configurable) location, add a link to the file and display it inline.

> The other problem is speed of typing is irrelevant

Yes, but having an interface which is reasonable and configurable is important for managing cognitive load, and Emacs excels here.

[1] https://github.com/abo-abo/org-download

Doing less work is pretty much the programmer creed. But that statement has several dimensions. Including having to do less configuration and tweaking work.

I think a modern lisp based editor, with concurrency/threading built in. With Racket/Clojure/CL backend with modern controls builtin would be all we need.

You still keep the emacs spirit, but with modern outlook.

> I think a modern lisp based editor, with concurrency/threading built in. With Racket/Clojure/CL backend with modern controls builtin would be all we need.

Sure, but it's the same as the "replace (La)TeX" problem: part of the value of the ecosystem is the huge collection of packages/extensions.

But if there was a reasonable way of porting packages over to a CL/Scheme new editor base, I agree that would be good.

> Including having to do less configuration and tweaking work.

Sure, but a bad, unconfigurable tool is more work.

> Emacs was invented for a world where Text was everything.

Text still is mostly everything for all of my backend programming, note taking, etc.

> The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does.

Typing speed is far from the most important part. It's the consistent interface for everything, reduction of cognitive load, and everything being available at your fingertips in emacs.