A Spiritual Successor to Emacs | Hacker News Reader

A Spiritual Successor to Emacs

vivekhaldar.com

83 pointsAmorymeltzer57 comments

> You can start climbing the levels of Emacs proficiency, a ladder that has no end

I switched from VSCode to (Doom) emacs and I think this point is important. With VSCode, my productivity had been constant over time. From the first time I opened the editor, it was intuitive, and my workflow barely changed over the years. It has amazing defaults that just work. Most people don't ever think about making significant changes to these defaults. Extensions do lots of magic and I just cross my fingers that they work as advertised.

With Emacs, I was less productive the first 2-3 months after switching. Then I got to about the same level of productivity I had with vscode. A couple more months later, I think I am now more productive than I was with vscode.

> A couple more months later, I think I am now more productive than I was with vscode.

What things in Emacs have made you more productive than you were with VS Code?

Not sure about the OP but having used Emacs for 4 years and being proficient in Elisp, just the fact that I can spend a small amount of time writing Emacs lisp to automate anything. Like for example spending a few minutes to make any Jira ID text a link to the tickets page, list my GitLab ToDos at the bottom of the screen, or perform complex multi-step data manipulations/visualizations accessable from a single key binding. The more things that enter Emacs, the more things can be automated together.

Wouldn't those things be better done at a meta-level with watchers/pipes/scripts, or in a build system?

Could be, I guess it just depends on the context. Emacs shines when it involves interactivity. For example, recently I was exploring a large CSV file with some columns being base64 encoded keys. So when exploring this dataset, it was nice to come up with a command to get the item, base64 decode, perform HTTP request, get the response, and display it in another buffer pretty formatted. Making a command to do this in Emacs Lisp is surprisingly easy (just need a few functions like thing-at-point, base64-decode-string, request, insert, display-buffer, and json-mode). A shell script for this use case may lack the desired interactivity.

This would make a great emacs workflow demo video. Maybe I haven’t been searching for these videos in the last few years, but they don’t seem common. However, I think such examples could help developers increase their productivity while also energizing a new generation of emacs users.

What do you mean when you say "interactivity"? I'm a vim user, so I feel like I'm missing some context about how emacs is used or understood here...

Can you share this piece of code?

the "e" in emacs

no, not "escape" (escape meta alt control shift)... but "extensible"

The "e" in Emacs stands for "editor", if anything. The name "emacs" originates from "editor macros". Your point still stands. Emacs embodies extensibility.

- Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows

- That I don't need to switch out of emacs for git (magit is great), complex file operations (dired), and other things like repl/shell/complex rgreps/etc

- Vim keybindings. I know this isn't related to emacs, but with Doom emacs I forced myself for the first time to rely much more on keybindings. I could probably do something similar with vscode, but it's not built for this and doesn't encourage it. It's painful in the beginning, but over time you're much faster with these keybindings.

- In general, I feel like I can customize it. I feel like I have control. For example, I had a painful time managing nested projects using multiple languages in vscode. The LSP extension's "defaults that work most of the time" get in the way when you're doing something that's a bit esoteric. With emacs I can easily customize it. This is just one example, but the point applies in general.

> - Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows

This. So much. The number of times I have seen people fumbling around with multiple VS Code windows and closing and opening it again in another directory, because the working directory wasn't right and switchting between loads of tabs they opened, overflowing the tab bar ... It isn't even funny any longer.

Another point to that is, that in Emacs I can press `C-x 1` at any time to get everything except the current buffer out of the way, using all the screen estate I want for some buffer, be it a shell or a code buffer.

> - That I don't need to switch out of emacs for git (magit is great), complex file operations (dired), and other things like repl/shell/complex rgreps/etc

Same here. I feel like I get things done in git 3x faster than what I see people do in VS Code or IntelliJ based IDEs. I just know my keys and do it much faster, which leaves me more time for the actually important thing: The commit message. Also being able to copy commit ids and branch names out of the magit version of log (M-x magit-log RET -c b if my favorite) avoids typos and improves my speed. Add to that the fact, that of course Emacs stores last used commands of M-x. Or interactive command input history, which one can cycle through easily.

On occasions, when a refactoring is needed, most of the times I can do it quickly via opening dired, moving the point to the directory I want to replace in and pressing Q. This basically always works, but does not have knowledge about the programming language. On even rarer occasions, I can feel a bit of regret of not configuring my Emacs even more, to support refactoring for Python. But I am sure, if I had to do it more often, I would put my mind to configuring Emacs and would configure it to have better Python support. Probably I can just find a tutorial in 1min of searching for it.

So people can tell me stories about how their IDE is more efficient all day, until they can show me they are up to speed for all the other actions besides refactoring with language understanding, which only happens rarely, I will not be convinced, that it would make me faster.

I have been using emacs and dired for like a very long time, and never knew about Q operations from dired. I used to do rg + edit mode...

I guess this is the thing with emacs, you always have something to learn...

Are you actually more productive in writing the code that you being paid for, or do you feel more productive, but are actually spending your mental energy and time writing custom Emacs scripts?

Interesting I have installed choco doom and I will try to experiment this myself. Talk to you in a couple of months.

There's this adage saying that no two Emacs configuration are alike, and I concur. Not because of users' uniqueness but due to fact how flexible and malleable it is. It's like a mouthguard that even if it has same brand and colors it's always going to be different - everyone has different print and forming process is unique too.

There are many reasons for that - some good, some bad - but in the end I believe it takes very special kind of user who decides to use Emacs over other solution: one that hates being limited by tools so they pick ones bigger than themselves and care for it deeply.

A lot of people don't care for their tools and that's OK - it's not a requirement to get sh*t done. Some of us do, though. Development tool has to allow be cared for, though. If I don't tinker, work around, re-paint and otherwise spend time improving, I can't really build such connection.

This connection and a promise, that I can hack everything anytime is Emacs spirit. Fact that it has stable development and decades of consistence only adds to it.

Beautifully said. Wholeheartedly agree.

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

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

> 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

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

Hmm, interesting article. I think I disagree with some arguments though. Eg I think one can make a bit of a lisp curse argument when the alternative is C, but I think that mostly doesn’t apply when comparing with JavaScript. Sure there are janky features but modern JavaScript is a pretty nice language.

Indeed, I think there are deficiencies in elisp that make Emacs Emacs. In particular there’s one big namespace, no modules, and not really any hidden state (you could let over defun with lexical scoping turned on but unlike JS where the module system is somewhat modelled on the old immediately-invoked-anonymous-function thing, no one does that). This then means that any extension can mess with any other extension. Elisp has features that make this work better, eg buffer-local variables, dynamic scoping (of globals), and advice. What in Emacs is implemented with buffer local variables is likely in a newly designed system to be some private-to-the-extension object associated to buffers / weak hash table mapping buffers to data.

I think Emacs-style extensibility also makes things hard because it is easy for two extensions to interfere unintentionally.

I somewhat agree with the idea of ‘barrierless extension’ but not for the reasons given in the OP – that eval exists.

I would say some differences are:

- many Emacs defaults are old, weird, or wrong. It seems mostly hard for them to be changed. Many packages also require much custom configuration. VS code started with more familiar defaults, no legacy of terminal interfaces, and has product people willing to change and improve defaults and generally set direction.

- Emacs is designed to be hacked on. The community around Emacs want things to be hackable, eg a popular way of installing third-party packages, straight, has features to support user-modified versions of packages. Also the language/environment exposes lots of extension points (hooks, parent modes, configuration in accessible global/buffer-local variables, advice). It seems that VSCode doesn’t have this. I suspect that bugs for VSCode are less common than for Emacs setups with a bunch of extensions (giving Emacs more VSCode-like features), but I also suspect that most Emacs bugs may be relatively easily debugged and fixed in a way that isn’t true for VSCode.

> Emacs is designed to be hacked on.

I don't consider VSCode to be in the same family as Emacs, let alone a spiritual successor, and really this is the sole reason why.

But, full disclosure, while I've used (and use) Emacs quite a bit, I'm really a vi guy.

As to the defaults, yes, you'll want to change a bunch. But personally, I find that's no less true for VSCode or most other such beasties.

> it is easy for two extensions to interfere unintentionally

This is true in theory but, in two decades of pulling in lots of extensions and writing lots of custom Elisp, I've ≈never seen extensions interfering with each other. I've found the vast majority of Elisp code to be surprisingly robust and pleasant to work with despite flaunting software engineering "best practices". It's gotten me to fundamentally rethink what it means to write high-quality code!

> many Emacs defaults are old, weird, or wrong

This is definitely true. Hopefully distributions like Spacemacs and Doom Emacs help with this, but I expect base Emacs is always going to be a bit wonky :P

look, I know emacs has higher limits in terms of ultimate functionality with lisp, but sometimes I truly wish the core language of emacs was python

> Sure there are janky features but modern JavaScript is a pretty nice language.

“Janky” is an understatement. Recently I’ve rediscovered that in JavaScript comparing two arrays with == and === returns false, unless they’re the same object. At the same time there is no built-in function to correctly compare arrays for equality. This is a C-level foot gun. Not the only one I might add.

I did the opposite:

I took very seriously studying and setting up neovim. I've been using vscode and sublime text before that.

After 3 months, I found an incredible amount of edge cases that I don't want to deal with, especially surrounding shortcuts, which is a core part of a text editor from my perspective.

I gave up, in the end I spend way more time reading code than typing code, my time is better invested into studying documentation than learning how to "type and modify code faster". I do most of the coding in my brain either way and the customizations I have on vscode are sufficient.

I will admit that I came with an understanding that wasn't satisfied, that is: I thought vim is made to be used "only with keyboard", meant that it had an exceptional keyboard-only experience. That's not the case, it has a keyboard-only experience, but it's far from optimal, there is a lot of customization that needs to be done either way and the documentation for such customization is not there, you have to mix stuff between vim and neovim.

What were those edge cases? The one thing that ticks me off about neovim is that they somehow managed to break the sudo write trick when you forgot to open a file with sudo

    :w !sudo tee %

I don't remember all the ones, but the obvious edge case is the inability to bind all the keys I wanted. I had to do a combination of terminal emulator with full shortcuts support and then a mapping mechanism. That to me was extreme. I don't remember which hotkeys can't be used by default, but it was more than one

There are limitations on which keys you can bind in certain terminals. Other than that most people can probably not at all corroborate what you said.

Isn't that exactly what I'm talking about? You can't bind certain keys in certain terminals.

A few that I clearly remember: ctrl + shift + enter. This can't be bound separately from ctrl + enter (or just enter at all?), because shift enter doesn't lead to a "capital case enter".

Same goes for shift + enter.

So what I did was using a separate terminal emulator (alacritty) and mapping those to a key I wouldn't use, such as F12 o, for example. However figuring out the character code to bind f12 is also another business.

Again, I solved that, but binding shortcuts to me is possibly the most essential feature of a text editor and the operation was highly unpleasant.

Did you try using leader keys? The issue with key binding in vim is that because it's a modal editor, custom shortcuts with the usual modifier keys (ctrl/shift) may conflict with existing shortcuts. But that's what the leader key is for, it allows you to bind an alternative key as a modifier, and use that for all your shortcuts!

I did, but there are some things that I use too often, so I'd rather have them as shortcuts.

I used AstroNVIM which comes with space as leader key by default (really nice!)

If you want to use it like a GUI app maybe you should use a GUI version of vim, which doesn't have that limitation. But if that was really was broke the camels back here's the result of a 10 second search on google with solutions for urxvt, kitty, alacritty and iterm2, as well as a note that GVim doesn't have that limitation.

I'm sure that's not the real reason why you couldn't get used to neovim. People have different preferences after all. Otherwise we'd all still be using notepad.

https://stackoverflow.com/questions/16359878/how-to-map-shif...

I used Astronvim with alacritty, I still found the setup incredibly convoluted, but you are right that wasn't what broke the camels back, that was the last straw.

In the end, I'm happy where I landed. I like the idea of vim, I don't think the editor is where I would like it to be. I think neovim will get there since it allows normal GUI editors to be built on top of it, which is amazing, but the documentation right now is a "disaster": you need to know VIMscript + LUA to be able to configure it, for someone coming straight to neovim, that was really annoying. But if you go to normal vim, then there is no language server, which is a problem on its own.

Either way, as I said, I'm happy where I landed. I'm not saying "no", I'm saying I'd rather use my time toward something else. I even use VSCode in a weird way, like I don't use the integrated terminal at all and I like "full screen view" when I'm typing code.

My only gripe with vscode is the terrible fuzzy finder for files. I do miss FZF, but I can do `code CTRL+T` in my terminal for a similar result

A lot of what I like Emacs for is reading—especially navigating through—code. One of the main upsides of a keyboard-first design is how natural it makes it to navigate through a codebase with higher-level navigation commands (like moving based on blocks/expressions/etc). I've been learning a new messy codebase recently and jumping around quickly without losing flow is powerful. I love being able to quickly throw up a second view into the file I'm working with and jump to the part of the code I want to compare or reference, all within the same mental space as I use to move around and edit code normally.

I prefer by far mouse-based reading, hence it did not work.

And navigating through blocks/paragraphs didn't turn useful at all at the reading time, usually I read things at a high level and read in deep details only if everything else failed. In that case, I'd rather read every line to have a great understanding of what's going on.

I guess that explain why it did not work for me, my philosophy goes against the editor philosophy.

I first learned about the DWIM (do what I mean) concept from Emacs. With a little elisp knowledge you can tweak your editor behaviour to do exactly what you mean. This can be really fun (tinker) and rewarding (itch own scratch).

https://xenodium.com/emacs-dwim-do-what-i-mean

When you feel so at home with your editor’s configuration, you kinda want it to apply to all kinds of apps and often bring more workflows into Emacs. Email, note taking, and one of my favourite migrations, the shell:

https://xenodium.com/yasnippet-in-emacs-eshell

vscode is interesting[0] but based on the grunts in my vicinity at work it has some serious glitches:

- file tabs going somewhere (tempted to say disappearing but who knows, they just evaporated)

- strange workflow, git extension forbids you to edit a staged file without unstaging, requires a few click everytime

- previous point hints at a slow / clickfest culture, what is transparent in magit, and also in normal git usage, needs extra disruptive steps

- strange readline behavior in terminals (maybe they were inspired by emacs term madness :)

- requires a modern machine (vscode is the only piece of software i've ever seen that will slow down keyboard input handling to less than 1fps. on a core i5 gen2, fresh install, empty project, empty file. that was something)

being js based allows for nice things, i wonder if you can extend things on the fly without creating an extension

[0] even though i love frugal and simple ui/ux, text and all that, I'm still curious about what a dom based editor can bring, in terms of stable layout for fancier information presentation while coding. Emacs buffers and GUI is quite limited here.

> vscode is the only piece of software i've ever seen that will slow down keyboard input handling to less than 1fps. on a core i5 gen2, fresh install

Interesting! I had (sort of) the opposite experience.

I loaded VS Code on an old netbook and braced myself for a horrible experience... but it was actually pretty responsive. I was honestly shocked at how well it ran, considering how slow the computer was. Sure, VS Code was definitely slower than Vim, but it was fast enough that I kept using it (for the excellent TypeScript integration).

Interesting, my machine was really empty so I wonder what caused it to lag that much. Maybe a strange issue on that version.

> file tabs going somewhere

I'm going to guess this is the "preview" misfeature, where if you open a file in certain ways (e.g. by jumping into it with one of the go-to-something commands) it gets opened in a weird transient state and converted to a normal tab on edit or closed on navigating away. You can turn that off.

sounds plausible indeed, i'll notify my colleague

I think this is way too nitpicky. Yes Emacs differs from VsCode in that it's a much more 'live' environment due to the mentioned interactive lisp-like nature but this isn't how you use emacs 99% of the time. People write their config, update it, they don't interactively hack on it all the time in ordinary use.

The comparisons that Carmack made I think are largely correct. When I first stumbled over Dendron (https://www.dendron.so/, great extension btw), was when I noticed that VSCode's extensibility is not unlike Emacs. And while there are no emacs "buffers" the interface is very uniform. You can seamlessly go from using say Dendron, to your debugger or your editor etc. And the command palette "everything is a command" flow also mirrors emacs M-x.

The spiritual successor to Emacs is ... Emacs. This is abundantly clear since it's actively maintained.

Just as in religion the spiritual successor to the catholic Church is the catholic church: arguing somehow the reformation changed that is to misunderstand what a code fork is.

Wait what? VSCode doesn't have macros?

I probably use them several times a week in Emacs. It's not a power feature but something very basic.

Probably not out of the box, but it's possible using the vim plug-in.

The difference between Visual Studio Code and Emacs is the difference between an extensible editor and an editor that is designed to be extended and modified as you use it.

It can take just a few lines of Emacs Lisp code to add a useful command. You can do it right in your editor, eval it in place, and save it if you like it. Extending VSCode consists of generating a skeleton with yeoman, adding the requisite methods to e.g. register the command in the command palette, testing with a special extension-testing instance of VSCode, then bundling and packaging the extension. Installing an extension locally takes invocation of a special command, what you're supposed to do is publish it to the VSCode extension marketplace.

damn. I thought you were proposing one I hadn't heard of before.

I think I agree with Rossum. As far as software architecture and functionality is concerned vscode has become a sort of spiritual successor to Emacs. The most significant enhancement being that Emacs is just a multi-modal text editor and vscode takes this concept an moves to the project level while maintaining many of the same implementation ideas from emacs. In this sense it's like a spiritual successor to the technical concepts in emacs.

Atom was intended to be the modern spiritual successor to Emacs. (It claimed to be ultra-hackable.) It failed due to its miserable performance. Visual Studio Code succeeded because of not being one.

Tell him VSCode have developer console to eval in each "buffer"

Great analysis. I love emacs but I would rather anything but GNU software since they've been doing weird stuff for a while (see gcc vs clang). If there were another non-modal/chord-based editor, with as good language integration as elisp in emacs, I'd be up for it. There's mg but it has no embedded language. Edwin but Scheme is too rigid a language.

I'm on the lookout but haven't actually seen any real spiritual successor.

Lem is basically a Common Lisp Emacs. I think Hemlock might still be around too. I’ve heard talk Nyxt Browser[1] is looking to add editing at some point but that’s a ways off. Still a browser based Common Lisp emacs definitely excites me a little.

[1] https://nyxt.atlas.engineer/

You're being disrespectful without reason towards a great many volunteer-run open-source software projects (maintainers and contributors), including many very significant projects. In fact, you're doing something very much akin to spreading a conspiracy theory.

> I love emacs but I would rather anything but GNU software since they've been doing weird stuff for a while

There's no "they" here, each GNU project is independently maintained, in general. There are some subtleties, but that's beside the point.

Reply on news.ycombinator.com