Comment by lispegistus | Hacker News Reader

Comment by lispegistus | Hacker News Reader

Parent Full thread

The reason VS Code is not the spiritual successor to Emacs is because Emacs is an attempt to preserve and further develop the legacy of the lisp machine. While VSCode is an attempt to capture as much of the developer editor market as possible. The old joke about Emacs being a great operating system but having a lackluster editor? It's actually literally true. A spiritual successor to Emacs will not be a text editor, it will be a software environment that continues and further develops the principles the lisp machine operating systems were build on, it will just happen to edit text on top of everything else it does.

On a different note, while I concede that VSCode is "good enough" at most text editing, and might even be excellent at some things, I could absolutely never use it because I have an insane grudge against Microsoft as the supreme enemy of Free Software. That's another thing an Emacs spiritual successor will have to be, not in any way shape or form associated with the devil of the church of GNU.

> Emacs is an attempt to preserve and further develop the legacy of the lisp machine

I don't think that is true, given that GNU Emacs either was based on principles of general Lisp implementations and it violated / did not support much of the MIT Lisp Machine (GNU Emacs: it's not a computer, the Lisp power was weakened, low-level Lisp was replaced with C, weak GUI, not GUI-first, it's not an operating system, ...) ideas.

> A spiritual successor to Emacs will not be a text editor, it will be a software environment that continues and further develops the principles the lisp machine operating systems were build on

I would think the first part ('software environment') is a useful goal, but the second part ('principles the lisp machine operating systems were build on') is not useful, since the Lisp Machine operating system is very foreign to modern users and very different what people know how to develop and use. That idea is also not supported by the user community. It would lead into a very small niche.

Emacs was written in a time where security wasn’t a positive consideration but a nuisance. So it was made using the belief that the editor should have complete access to any function within the editor program. trust isn’t something that scales well and if eMacs were to lose that trust within its community it would become more akin to a full blown operating system with security levels and protocols between different functions

> Emacs was written in a time where security wasn’t a positive consideration but a nuisance

Thank god that today we are much better with browsers running remote code, having indiscriminate access to your filesystem, camera and microfone and syphoning data to mothership. /s

What kind of security concerns are there for an editor, that tries to fulfill wishes of its users? The user wants something, (might have to do some work for customization and), the user gets it. Anything else seems limiting.

Since the last several iterations of emacs have emphasized package management from 3rd parties, I doubt most new or even experienced users are looking in to if someone slips through malware in an update or a similar package to a popular one like has happened with npm

Reply on news.ycombinator.com