Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CLI much much convenient and faster than moving hand to reach cursor keys.
My only gripe is that Firefox and its derivatives it doesn't work any more. Long time ago it did work. And I have no idea why feature was dropped some rewrite.
Nothing else is capable of handling the variety of text-related things I want from my text editor.
- I consume HN and Reddit in Emacs. Allows me for example to quickly search through all the links shared in a thread.
- I read Jira and Slack in Emacs - in org-mode. It is far better for finding relevant things, extract them for my notes, etc.
- All my writing done in Emacs. Because I have: spellchecking, thesaurus, etymology and definition lookup, translations, LLM integration, etc. All my notes are in Org (Zettelkasten style).
- All my spaced repetition cards are in Org-mode (they are parts of my notes, I don't need a separate system to manage them). I can generate number of cards to study a topic, from selected notes.
- All my AI sessions are in Emacs. It's amazing that I can send just about any text to an LLM, anytime, anywhere. I can do it in the middle of typing a message, like this very comment.
- I watch YT vids controlling the playback directly. I can pause, rewind, speed-up, mute, extract transcript, etc. - this is indispensable while watching and taking notes.
- my email client is in Emacs (of course, why not)
- my Telegram client is in Emacs. I can easily retrieve a video from any web page and send it directly (without linking the page).
- I can extract any part of my screen and OCR the text out - it pops up in an Emacs buffer.
- I perform all searches from Emacs - I can google, duckduckgo, brave, HN (algolia), wikipedia, etc. I search through my browser history in Emacs.
- I can control my browser tabs, switch between them, find matching lines on the page, jump to links, etc.
- I read and annotate PDFs in Emacs.
- And I haven't even touched anything programming-related (tons of things)
Why, oh why would I ever feel unsatisfied, hoping that there's anything else that can help me do things better? Honestly, there just doesn't exist a piece of software that could help me do even a subset of things I can easily achieve with Emacs. You'd ask me that question in 20 years, if I'm alive and still using a computer - the answer would be - "Yes, what else would I use?"
I'm currently using my custom fork of thanhvg/emacs-reddigg. It isn't ideal, I've been itching to rebuild it into something more robust. Well, one day I may get annoyed enough and just do it.
Nearly 40 years for me. Wow! I’d note that MacOS input fields also have basic Emacs bindings for cursor movement, not just shells and browsers. Works in MacOS Mail, Evernote, etc.
Yes, emacs keystrokes became kind of cli lingua franca, which apparently many do not know. I don't remember my self ever read about those supported explicitly anywhere, but accidentally I found out long time ago and then whenever I try new systems, programs and whatever I try which keystrokes do work. Quite often at least some work.
It's GNU Readline[0] or similar. It's all over the place, on Linux at least. Being GNU it defaults to emacs, but the vi support is also excellent. The first thing I type in any foreign bash is 'set -o vi'.
Yes it's GNU readline, but note that the very Wikipedia link you gave explains that it's GNU readline that re-used those shortcuts from Emacs, not the other way round.
So it's not wrong to call these "Emacs" shortcuts.
It annoys me so much to have learned that GTK text fields used to have an Emacs editing mode, which they've hidden behind an unaccessible configuration option, and now it's hopelessly broken in modern GTK version.
I spent a day or so hacking around with kanata[0], which is a kernel level keyboard remapping tool, that lets you define[1] keyboard mapping layers in a similar way you might with QMK firmware. When I hit the control or meta/alt/option key, it activates a layer where Emacs editing keys are emulated using the GTK equivalents. For example, C-a and C-e are mapped to home/end, etc. I preserve my macOS CMD-not-control-key muscle memory this way too.
The only problem is, this is not the behavior I want in terminals or in GNU/Emacs itself. I wrote a small python daemon (managed by a systemd user service) which wakes up whenever the active window changes. Based on this info, I send a message to the TCP server that kanata (also managed by a systemd user service) provides for remote control to switch to the appropriate layer.
Nope. And I’m probably not a great person to write it. I’m hardly an Emacs power user. I had friends who would do everything in Emacs to the point where I would joke with them that Linux was just their Emacs boot loader. I keep lots of other apps and term windows open. My init.el file is pretty simple. I’m often aware of a vague capability that Emacs has, but I’ll brute-force my way through an editing task with keystrokes and some keyboard macros rather than add a new fancy library, at least until I’ve been forced to do the same thing a couple times per month. That said, I do remember trying to use Emacs on a 300 baud dial-up link. That was painful, though truthfully everything beyond ed would be painful at that speed.
I'm curious... why are people (this thread, but there are several independent others) replying to "Is anyone still using emacs?" ? I don't see that sentence anywhere in the article!
Sure, and I'm not arguing that the answers are uninteresting, but I found it odd that this is being double-quoted several times as if it was taken out of the article.
It's 26 years for me. Emacs is I believe the oldest software I still use. I started on an SGI Irix in 2000. I used it also on HP-UX, Solaris, Windows, MacOS, and of course all varieties of Linux
> Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
And many keystrokes work on MacOS, too. That was a pleasant surprise when I got a Mac laptop for work.
It's quite difficult to find software older than Emacs in widespread use. Emacs is one of the "original" software, the first GNU software for which the GPL was created. It competes with vi, whose direct lineage has been broken (nvi and vim are reimplementations).
> It's quite difficult to find software older than Emacs in widespread use.
Agredd! Aside from the basic Unix commands (ls, cat, etc), the only substantial program that I use today that I also used in 1991, is emacs.
Well, and perl. I don't write much perl these days, but I have tons of perl scripts accumulated over the decades that I use daily so that counts as using it.
Third oldest for me would be mutt, which is still my primary email client. But I only switched from elm to mutt in.. not sure maybe 1996?
One advantage of vi is that even though emacs is available on all those systems, vi is actually installed on all of those, setting aside windows. If you know rudimentary vi you can walk up to any of those machines and edit a configuration file well enough to work.
vi isn't even in the same neighborhood in this regard. You can and should learn vi (and ed!) in one afternoon even if you never use them. Whereas Emacs isn't something you just learn in an afternoon. (And vim is not the same as vi)
That is a separate discussion from whether you should use ed or vi normally. You learn the "fallback" with the hope of never being forced to used them.
I don't like keyboard-centric text editing. Yes GNU Emacs supports the mouse, but just like Vim the experience is miserable. You can spend a lot of time configuring it, but at some point you're just writing extensions of extensions just to get a basic GUI flow that isn't painful, and no matter what it'll never feel quite "right". The program just wasn't built with the idea of a mouse in mind, and bolting it on really wasn't sufficient.
Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.
I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.
No. Even most keyboard-centric text editors implement mouse inputs, with only a few exceptions coming to mind, almost none of which anybody uses today, for example ed. In fact, most editors don't even restrict text insertion and deletion to keyboard input, which is what you might be confusing with "text editing", which might be more clearly expanded to "operating a text editor".
The only reason why I was taught vim is that a coworker wanted someone to know it so they can explain why emacs is better. It didn't work and I've transitioned to neovim.
I use Lem. It's an "emacs" but not a clone of GNU Emacs. It's written in Common Lisp, extensible in Common Lisp and it's way more performant than GNU Emacs. Obviously less features and plugins but for my needs (writing Lisp code mostly) it's great.
Dunno, I've been trying it off and on since it was first released in like 2018. I don't theres any particularly noticeable changes from 6 months ago specifically.
I also used Emacs way back in the day but have been Vim/Neovim for the last 5 years or so. But I recently started a new Lisp project so revisited Lem, actually set it up the way I want (with LazyVim-like bindings), and found with my changes and comfort hacking on it (it's all Common Lisp top to bottom so it's easy to change) that it can replace LazyVim for me now. Just using the ncurses front end BTW.
I'm a die-hard vimmer. I use vim-motions everywhere - they permeate my editors/IDEs, browsers, terminal, I use them system wide (e.g. to change volume or control media or my WM). One day I woke up with the realization of the fundamental truth - Emacs simply vims better. Much better than even Neovim. I just had to master Vim and grok some Lisp to arrive to that conclusion.
People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.
Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.
If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.
So? Emacs has built-in solar and lunar calendars, has world-clock command, format-time-string accepts ZONE argument. Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones? This can be done in less than 15 minutes. With AI maybe in 20.
You're not dealing with an app you paid for, and your complaint not even an accurate one: Org's timestamp format doesn't encode timezone by default. Emacs absolutely supports the feature you want, you just didn't know about it.
Oh, you can't imagine how I'd like to be proven wrong.
Last time I checked, proper timezone support wasn't there. One could specify single timezone for entire org engine, but not per timestamp. I found some nearly official mailing list thread where participants couldn't settle on a single solution, and so the conclusion was that proper TZ is not coming to org.
> Org's timestamp format doesn't encode timezone by default
> format-time-string accepts ZONE argument
Isn't format-time-string just a visual decoration? Last time I checked, agenda and all other plumbing always treated every timestamp as local (to the TZ configured globally). And so if I recorded that I have a meeting at 1PM London time, my org-agend would show it to me 1PM even if my TZ is set to New York.
> Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones?
Can you elaborate? My understanding was that I'd need to rewrite entire org in order to support time stamps with mixed time zones embedded in them.
> You're not dealing with an app you paid for
Actually, I'd be willing to pay above the competitor _subscritpion_ price for an org-based organizer with
- proper TZ support
- conflict-free sync between devices
- (cherry on top) touch UI friendly Android client. But honestly, orgzly would do, as long as it supports the above
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
* Meeting
:PROPERTIES:
:TZ: Europe/London
:END:
<2025-06-01 12:00> ; UTC
2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.
The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.
Aren't Org mode dates ISO 8601? ISO 8601 has an optional timezone, is that not supported in Org mode? You could then use format-time-string to configure how it is displayed.
Another possible solution. Often - but not always - a datetime and timezone pair can alternatively be represented as a UNIX timestamp. Depending on the use case there are tons of ways to manipulate UNIX timestamps, and Org mode might support that naively (I'm not sure, try it).
I suppose that you mean via some third party cloud. I personally sync my Org mode notes via adb when I backup the phone occasionally. I read on the phone using Orgro.
If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!
"If emacs is not installed on a system, I use sed."
Bill Joy (creator of vi) once said that if he sits down on a foreign system, he reaches for ed [1].
To be fair, both emacs and vi have "magic exit incantations", though if you have emacs perhaps you have a menu in GUI mode. If not, C-x C-c is really not any more memorable than :wq! The vi one at least has an obvious mnemonic ("write quit") but either way, you need to know an arbitrary sequence of keystrokes.
NeoVim because it's fun!! So many plugins and colorschemes!
So customizable- these days Claude will just change it for you, no need to learn the APIs if you're just interested in the result. Yes you're AI-slopping your config, but the drawbacks to that are super low (it's a personal editor, not something I'm inflicting on others)
AI slopping my config is what allowed me to learn vim without going through the pain of setting it up. I can ask AI to teach me about some motions or set up some configs for m in lua without ever know lua. This is the biggest impact of AI in my professional life.
Vi is fine. It's superior and to bare ed - The Standard Editor*, when you don't have anything else available. I made much of my living coding vi 7 years in -80's. And I still use vi, when emacs is not there or system has so little memory that emacs is too much. Which is usually with a embedded systems or some old Unix on single mode fixing unbootable system.
For Firefox I've switched to Glide (Firefox fork?) and configured it to implement Emacs keybindings. There is a config on the project's Github discussions page that I started off of.
> Emacs cursor movement keystrokes are quite widely supported elsewhere too
Yes, even in Codex and Claude Code.
> Those work well also besides shells with Chromium/Chrome/Safari... My only gripe is that Firefox and its derivatives it doesn't work any more
Interesting, my experience is exactly the opposite: I had to finally bite the bullet and migrate to Firefox because Chrome/ium switched to GTK4 which removed key themes support.
(That's OK though, I should've moved off Chrome a long time ago.)
There are so many fad technologies out there, but vim/emacs and unix command line in general are skills you can invest in that stay relevant for 40+ years.
Weell, it's not completely untyped, but it is runtime type-checked. There's stuff like `(if (integerp foo)` and `(defcustom ... :type '(choice (const tag "abs" abs) 'integer))`
And then there are more ambitious projects like the static analyzer and language server https://github.com/emacs-elsa/Elsa
I haven't tried Elsa yet since it seems to require setting up a package manager like Eask (I don't really understand why I have to install a package manager to run a language server, especially when they support four emacs-specific package managers?) and the docs were very light on whether eglot is supported or just lsp-mode.
A weird, inscrutable project management tool for the shell written in Perl 4 and Guile Scheme, that the ten people in the world who learned to operate it swear it is the greatest piece of productivity software ever invented.
Well, I've got to admit I've haven't read HN using emacs. Is there such a .el thing avalabnle somewhere? It would be great to read HN as it was with usenet news. Not joking, that would be excellent tools I'd like to have !
I started with gosmacs then switched to gnu emacs in 1985ish. So about 40 years. The renaissance of emacs development in the last decade has been very nice to see.
I just tried, and my macOS up todateFirefox (still Sonoma few weeks), doesn't work. Nor does Waterfox (Firefox derivativ) that I've been using more lately. Could it be some setting I need to set before it works?
Unless I misunderstood your question, are you simply trying to use emacs bindings in all text areas of the browser like the URL bar, any text fields on webpages, being able to move to the beginning or the end of a line, backspace, etc., go to the next or previous line, all with emacs bindings? That has worked for decades on Mac and it works for me now in all browsers.
Idk, its never stopped working for me for the past 10+ years. And Firefox has additionally always supported ctrl-n and ctrl-p working in the address bar for suggestions while Chrome has never supported this
I have never used emacs seriously as an editor, however, I couldn't work without magit.
I even manually build emacs 28 so I can re-use the same set of magit configure files.
Answering to preemptively asked question that doesn't appear in TFA: yup I sure still do.
If anything compared to the 486 days, back when Eight Megabytes And Constantly Swapping was a joke that made sense, my computer now instead of 8 MB or RAM has 32 GB or RAM (so 4096x more RAM, or 2 exp 12 more RAM: something something about transistors doubling every 18 months and all that)...
Who's laughing now? ; )
Seriously though: Emacs with native-compilation, tree-sitter and LSP support (and stuff like Magit and ripgrep integration too) makes it really amazing.
Yeah, emacs is very competitive with "modern" IDEs. Even in JVM languages, which for a long time wasn't true. And I don't know of anything, anywhere that can rival magit.
I've been using it for far less time than you have, began ca. 2011 or 2012 here[0], but over that time it has been my constant benchmark for what an editor should feel like, and every other IDE I've used has fallen short. With LSP especially, in the past 6-7yr I have actually been predominantly using emacs. Part of that was being fortunate enough to no longer have to work on much JVM stuff since ca. 2019, but it's also due largely to large advancements in emacs' capabilities.
EDIT: In particular, this is exactly where I fell down the rabbit hole:
> If you are not familiar with Emacs you SHOULD run the tutorial, which can be accessed in edwin by holding down the control key and typing h, then, releasing the control key, type t. (C-h t)
I don't know if there's anything else on the entire internet I can specifically point to that has had a greater impact on my professional life... strange.
Those keybindings work on MacOS for me, but not on Linux (by default).
There is a way to enable Emacs keybindings in all GTK apps on Linux, but it’s quite buggy in practice (many apps define keybindings that override or conflict with these), and I believe the feature is officially deprecated.
Yes. For me, on all MacOS versions from Catalina to Sequoia, the basic Emacs keybindings listed here work almost* throughout the operating system:
https://support.apple.com/en-us/102650
I don’t daily drive VSCode but I use it for teaching, and then basic Emacs keybindings like C-n and C-a and C-k work pretty much everywhere, from the command palette to the code editor, without any plugins.
I also don’t use Chrome as my daily driver, but keybindings like C-a/C-e certainly work in both text areas and address field, or I would have remembered it as one of the annoying exceptions. I do regularly use a few Electron apps, which are based on Chrome, and it does work fine there.
*: There are a few apps that deliberately break the Emacs keybindings. Microsoft Office is one of them, since they insist that Ctrl keybindings on Mac should do the same as it does on Windows, which is extremely jarring if you rely on the Emacs keybindings everywhere else.
Yes. Basic emacs keybindings work pretty much everywhere in macOS. I have run into a couple of apps that don’t behave correctly, but 99% of the time they work.
I am typing this in a textarea in Chrome, and the basic Emacs navigation commands all work: C-a, C-b, C-e, C-f, C-n and C-p. (The M- equivalents don't, though. You just get some special chars: å, ∫, ´, ƒ, ñ (dead char for the accent), π.)
Chrome Version 149.0.7827.155 (Official Build) (arm64)
Very similar in Visual Studio Code.
(I started using macOS in 2010, I think, and the Emacs-style shortcuts have felt pretty well supported the whole time. I can't promise that applies to Chrome as well though, as I'm not a regular user.)
I have been using VSCode for teaching the last few years, and routinely use a VSCode without plugins for that purpose, and Emacs keybindings work fine in its text area (the code editor itself). If it doesn’t work for you, then apparently something is broken on your computer. Not all keybindings work but the ones listed under Text Editing here certainly works for everyone else:
https://support.apple.com/en-us/102650
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)
Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
Besides the performance and what baokaola already mentioned some things that make Ghostel better than vterm especially when working with those cli agents are:
- proper handling of resizing windows
- progress reports (you get a spinner in the modeline when claude thinks)
- notifications (get an alert when your agent is done)
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
Of course. Emacs has been my stable editor over many years, handling many languages that came along, surviving many other IDEs that came and gone (the latest being the Cursor sold out).
There're always new enhancements in Emacs, from multiple-cursor editing years ago, to LSP and tree sitter in recent years. Currently I just got into the vertico/marginalia/consult/embark combo packages. Embark with its context based actions seriously is an amazing underrated package.
I also have been using emacs for almost anything for the past 20 years. I had to switch to VSCode for coding over a remote ssh connection to cloud VMs. The client/server split of vscode felt superior over the ssh connection and the emacs alternatives was not up to the same level of performance two years ago. Do you know any progress on that front? I would love to go back to emacs as my daily driver but I am sensitive to lags when I type / execute commands. Have you worked with ai assistants over a remote connection?
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.
Yup. I've aliased it to e and and it works just fine. Sort of "send file into Emacs". I've also added some elisp to say things like e something.c:43 so that it opens it up at line 43.
I used have a ep which I could pipe something into and it would put it in Emacs buffer but that stopped working somewhere I never got around to fixing it.
I used emacs for about 16 years, but never properly gotten into client-daemon setup. What’s your setup? Does the daemon preserve open buffers and stuff, so when you connect you have all your openned stuff? Or each emacs sessions have separate set of buffers and windows?
Yes to some extent. When you attach to it, the default screen will still be scratch, but all your buffers are still open. There are some settings you can set to fix that, if it's burdensome.
being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example
On my MacBook I map the right hand command key to “ctrl” and the right hand option key to “meta”. Since the command keys are right next to the space bar that puts the ctrl key on a thumb position most of the time, and for the times when that isn’t a good key for a given combo I still have caps lock bound to “ctrl” as well. Seems to work reasonably well and lets me keep the usual command and option keys on the left side for “super” modifiers and for typing accented and other characters.
For my desktops, I use an Ergodox EZ keyboard and mapped ctrl and meta into the thumb clusters there.
I don't use actual vim for much, most of my time is spent in JetBrains IDEs and sometimes Xcode. Both with vim emulation. Setting up Spacemacs would take hours of my time for questionable gain. If I was still a student I'd jump on it but alas
This works especially well on an IBM Model M because there's nothing in the vicinity of either the left or right ctrl, you just chop your palm down and can't go wrong. I could also pretty reliably M-x in one hit by flipping my left hand over, curling my pinkie finger, and hitting the keys with the knuckles. On more crowded keyboards I remap ctrl:nocaps and use thumb and forefinger for M-x. I actually deliberately got rid of my Model M to teach myself to do it this objectively worse way, because context switching between my docked workstation setup and laptop keyboard on the go was difficult. If only someone would make a laptop with a proper keyboard...
> for getting huge swathes of code on your screen at once
This is my major gripe at most IDEs. Every window, or view, or sub-view insists on shaving off a little bit of vertical and horizontal space for... I don't know, tabs or things? Or to tell me what program I'm running?
I just want a dark screen with text (I run Vim, so I'll concede I allow a tiny bit of vertical space for line numbers and a little bit of horizontal space for the command space)
I've been trying to use agent-shell with OpenCode but the abstraction that agent-shell puts on top of it is too much. I can't figure out how to change the model. The command to do it doesn't do anything; I see the correct model list and seem to be able to select it, but then it doesn't change. If I just run "opencode" in the same directory it comes up configured the way I want. The Claude integration works with that workflow too. Opencode comes up with some baby CPU-only model that I've never heard of, and basically, it outputs syntactically correct English sentences but doesn't seem to do much more than that.
Since I mostly use Claude I haven't fussed with agent-shell much yet.
agent-shell is awesome, but Anthropic banning subscription usage via ACP is a killer. I've liked claude-code-ide.el when I've used it, but its lack of concurrent sessions per project has prevented me from fully adopting it. I know, I should be using worktrees, but I still haven't figured out a nice way to get that to work with my docker-compose-based project (though I'm open to suggestions!)
This stuff all looks great, I can't wait to upgrade to 31 and then forget about all of it and just keep using Emacs the same way I have been for the past 20 years, /again/
The post not long ago about how far the built in autocomplete has come got me to trim down a bit of my config. Seeing that treesit stuff is getting folded in, I may make another effort at trimming down.
It is crazy nice how invisible the native compilation became.
Which autocomplete mode? fido-vertical-mode, completion-preview-mode, or something else that I should maybe look into?
I switched from vertico to fido-vertical myself, but still use company for in-buffer completions. I tried corfu and completion-preview several times but didn’t get something I’m happy with from it.
I'm glad to see that people are working on emacs, as I use it constantly. That said, I personally don't see myself really using any of the stuff highlighted in this article. I've never really been in to advanced auto-complete or tree-sitter type of functionality. Some tasteful syntax highlighting and indentation support is fine but that's about as far as I go. That, org-mode, and magit is about all I use for coding and text editing. I also use notmuch for email.
Systems like Emacs that are hyper-configurable via a text file seem tailor made for modern LLM's. If you've got a little bit of Emacs experience but bounced off of it because the learning curve was too steep I highly recommend diving back in with your agent. Agents are really good at setting up and maintaining your .emacs/init.el.
Doing this for Neovim at work and it’s so much fun. I justify the slopped config to myself because I want to get work done rather than learn the config of some random Neovim package and how it interacts with the rest of the system.
I can just ask Claude, “make leader / toggle a terminal at the bottom of the screen , and leader t swaps it to the right side” and it’ll just do that. I liked a theme but I wanted it to also change the status line of the focused window, and it just did that for me. I had an issue where the neo tree would freeze for a few seconds, and Claude figured out it was a bad interaction with the git in our toolchain, etc etc.
I have my very own text editor that I customized in plain English! I could’ve learnt spent hours learning Neovim’s style of Lua, researching packages, debugging, etc, but this gets the same stuff done way faster and lets me get to work. This was the biggest thing that kept me going back to either a preconfigured Vim setup like LazyVim or vscode. Definitely recommend.
My .emacs.d has been carefully handcrafted over years. My .vim/.vimrc accreted over the same period, bits copied in, commented out, …
Claude did my neovim in about 45 seconds, with the instruction “make it work like my vimrc but better and using the cool new stuff” and it’s great! Not my daily driver, but serviceable as EDITOR and prettiest of the bunch.
I agree this is great, but I also feel like it's an intermediate step to just asking Claude for whatever file edits you want... and then you don't even need the text editor.
I’ve always used vim/neovim but fell in love with some of the features of emacs (org, magit, lisp). My problem was spending the time to configure it though.
Even with spaceman’s/doom and the amazing documentation it was always still so much work to configure emacs as a newer user. LLMS have made this nearly instant.
This is a bit of a ramble but it’s so amazing having emacs and an LLM now, I don’t even touch vscode anymore and only find myself touching things like IntelliJ when I really need to dig into something with a debugger.
I may have to dive back in. I've been using lazyvim for most of my terminal work now because spacemacs was too much effort to keep running, where-as lazyvim is a git pull and done sort of thing.
Modern LLMs are ok with that, but they do make silly mistakes; and a major problem here is that your init.el stops being your own, if it’s written and maintained by an LLM, you will have no idea what’s going on there. And if you would be reviewing every single line of your init file, then what’s the point
That's a skillset any coder in 2026 pretty much has to pick up. If you don't understand the code an LLM writes for you for your day job then you're contaminating your employer's code base with slop. But if you don't use an LLM then you're not as valuable to your employer as you otherwise would be. So most of us need to figure out how to use an LLM and still understand the code.
Using an LLM on init.el is a lot easier than using it in your day job. A 2 line change that you told the LLM to make is easy to internalize.
A programmable editor really is so amazing now. You can have a LLMs whip up anything you can think of in minutes. Ive used neovim for a long time but never really customized it much. Now I’ve got tons of plugins and can add new features on a whim.
I’ve been thinking of trying out emacs because I think the native gui can probably be even more powerful
I know a bunch of people (including me) who decades ago wished they had a private sendmail.cf expert at their elbow, and even a few sendmail.cf experts who were sick and tired of always being asked to help random people with their sendmail.cf file for free.
Maybe there will be a resurgance of terribly obscure totally unique quirky configuration files for all these vibe coded apps, unique enough that they don't appear in the training data, so you have to hire real humans to sit at your elbow and help you!
Agree, I put off using org-roam a few times in the past because I couldn’t be bothered to keep my notes in such order. But now I have an agent that set it up and it’s also recording, organizing, and referencing everything.
If you do any kind of serious work, you need a text editor. Emacs is still one of the best around. It's fast. It's configurable. And it's under your control. You won't suddenly find your text editor "upgraded" with tons of new features you never asked for. It's all opt-in.
haha, I definitely wouldn't call my setup fast. But it did get a lot better after Native Compilation and a lot of the major stuff has started async to feel more responsive at least.
The default garbage collection tunables are also from 30 years ago. Adding the GCMH (Garbage Collector Magic Hack) package resolves much of the slowdown, and native compilation covers the remaining gap quite nicely.
>You won't suddenly find your text editor "upgraded" with tons of new features you never asked for.
I never asked for native compilation implemented via the trampoline technique, which increases attack surface (because it causes Emacs to routinely execute files in a known-by-attackers location in my home directory) and makes debugging harder, but I'm stuck with it if I want my Emacs to speak the Wayland protocol (and I do).
Hallelujah and thank you, sweet little baby Jesus. Now I can get rid of this bullshit from my dotfiles:
rm -rf ~/.emacs.d/tree-sitter
mkdir -p ~/.emacs.d/tree-sitter
set _plat = windows
if ( `uname` == Linux ) set _plat = linux
if ( `uname` == Darwin ) set _plat = apple
set _arch = x86
if ( `arch` == arm64) set _arch = aarch64
gh release -R emacs-tree-sitter/tree-sitter-langs download -p "*${_arch}*${_plat}*"
tar -C ~/.emacs.d/tree-sitter --transform 's/^\(.*\.\(so\|dylib\|dll\)\)/libtree-sitter-\1/' -xzf tree-sitter-grammars*.tar.gz
rm tree-sitter-grammars*.tar.gz
That's csh, BTW, just like the Founding Fathers intended.
I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesitter highlighting and LSP enabled by default. Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point.
This comment shows up on every single emacs thread and for the life of me I can't understand why. It takes one line in a shell to pull down a premade config and if that were to be built on, who would decide what gets put in? I don't think it's worth anyone's time to decide what everyone needs in a premade config.
The problem isn’t so much the difficulty in finding a pre-made config, it’s a combination of:
A) which premade config to choose
B) what half of those settings even do (and do you need them)
C) a lack of “sane” defaults that use the built in abilities
Realistically walking through the article authors “emacs from scratch” config and seeing what can be done with the built in packages and how is hugely instructive but even then you only get that from walking through the config one line at a time and reading “help” documentation for most of it.
At this point emacs is so old that fixing the problem of “sane defaults” is probably near impossible if only for how much it would break existing configs. But it might be a good addition to the tutorial to provide a set of questions and answers (possibly with demonstrations) that allow a new user to generate their own config with some nice defaults. We can assume these days that most new emacs users are coming from some other editors, so asking questions like “do you want auto complete suggestions in an inline drop down like VSCode” could be a perfectly reasonable question and then it could add the correct configuration settings to config for you using just the built in functionality
You are just worrying for no good reason. Doom Emacs and Spacemacs are both very good; being far removed from vanilla emacs is not a problem to be worried about.
Same, I use Spacemacs in holy mode, which is spacemacs with normal emacs key bindings and not vi modals, but still I wish there was a good config that was straight up emacs bindings and didn't pull in evil at all.
Last time I looked it appeared to be as simple as disabling evil mode and configuring a new leader key. But you're right, it's not a straight configurable.
Huh? Emacs is inherently a modal editor - transients, isearch, keychords, M-x - these are all forms of modality. Vim-motions simply organizing that all into nice set of patterns - memorable and very practical. Besides, both Doom and Spacemacs absolutely can be used without Evil layer.
This is a ridiculous collapsing of the sense of what people by "modal editing" into a homogeneous conceptual soup.
The core editing components of non-Evil emacs are direct manipulation, not modal. That there are modal aspects on top of that for doing things which practically/genuinely need a modal switch (command entry, search entry, etc) doesn't make the default emacs configuration a "modal editor" in any sense of which people actually apply those terms.
By your definition of modal, almost every application can be described this way. The point is not whether a system has modes, it's whether it makes its core emphasis and interaction modal.
You can see vi's motions as elegant and purposeful. I see them as an accident of history stemming from the poverty of the number of keys and capabilities of the dumb terminal it was designed on.
I encountered both editors in the late 80s and chose emacs precisely because it didn't have the "barely a step up from a teletype" interaction model that vi had.
As for Doom and Spacemacs without Evil.. yes... but why? Their original and state purpose was a packaging with a modal default. It's trivial to toss together your own init.el that brings in the same set of packages these days and with very little effort.
If the goal is an easy packaging of emacs with sensible defaults.. and then you have to go modify the defaults to make it what most people (yes, most) would consider sensible... No, that's not meeting the state use case.
> You can see vi's motions as elegant and purposeful.
Sure I do, and there's so much tacit knowledge that I can't ever explain verbally or in writing that goes into it, to the point that arguments like yours, challenging my "choices" would ever feel less disingenuous. It's like forcing a left-handed kid to hold the pen "correctly", due to religious dogmas. It just works far more naturally for me and thousands of other people, and just because you don't get it, it doesn't make the model useless. Try to see the other side, sometimes "dumb" ideas do work, and shit that works maybe ain't that stupid.
> Doom and Spacemacs without Evil.. yes... but why
Great question. Now maybe you're trying to learn something despite of "years of the opposite experience" feeding to your hubris. Doom offers a set of Lisp macros that come very handy - map!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, etc. - they genuinely can slash the inevitable boilerplate in the config. It's much easier to experiment with advising and instead then writing ad-remove-advice with different syntax, repeating the symbol names, etc., you'd simply prepend `un` to the form and eval it. add-hook! allows binding multiple fns to multiple hooks. And these are just some examples.
Also Doom does some tricks to make the startup blazing fast. Many times I have compared my config (that pulls over 350 packages) with someone else's vanilla. Doom demonstrably starts much faster.
I think it is cultural. It's kinda like building your own lightsaber as a Jedi. The part of Emacs/Vim initiation is building your own configuration that works for you. Setting up plugins, keybindings, colorschemes etc. It's part of the fun of it (at least for me).
Oh yes. What other software allows you so much to make it your own? Yes, I know the yak shaving argument etc. But what's the fun in opening up some computer/OS/software that looks and feels exactly like everyone elses? An Emacs (and vim) setup is something you can actually have a discussion about with someone else.
KDE, various window managers (i3, awesome, xmonad,...), the Linux kernel (there's so much stuff you can configure through sysctl alone, and that's just 1 single customization facility), SystemD, your shell (whether it be bash, zsh, csh, ksh, or something else), and the list goes on.
There's Bedrock, Centaur Emacs, Witchmacs, and more; even if you don't like Doom and Spacemacs there's plenty of fish in the sea. Though there is the issue where preconfigs tend to have edgelord 'Dark As My Soul' themes which make text absolutely unreadable, which is a bit of a pain to deal with.
Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.
It won't be a perfect transition, but it will make it a lot smoother.
Done this exact thing. Fed an agent my actual keybindings and `M-x` history, let it regenerate a lean init.el. Two notes from the other side of it. It's great at the 2% you named, but it silently drops the muscle-memory stuff you never think about: which-key, the half-configured LSP, that one hydra. Diff the old and new against a day of real editing, not against your memory of what you use.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.
Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
I've had multiple config bankruptcies over the years until settling down with Doom. I'm considered "experienced Emacsian" - built and published packages, etc. I'm still using Doom but only the core of it. I don't even consume almost any of its "official" modules - I have my custom ones instead. I have considered building my own config from scratch (yet again), but I like Doom's core macros - map!, add-hook!, defadvice!, undefadvice!, etc. I'd probably inevitably end up borrowing them and structuring my new config just like I already have, so I see no point.
> I don't fully understand the editor
Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.
> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature
That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.
Emacs is not great software because it has good features. It’s great software because it conforms itself and those features to the user’s needs and preferences. If one of those preferences is short, canned config, we’ve got a way to express that (spacemacs and doom). But if one can’t be arsed to express their preferences even in those frameworks … emacs might not be the software for them.
I'm getting pretty good with Emacs, but I find its Treesitter handling a bit obtuse, and the auto-installation package I found slowed the editor down a lot for reasons I can't determine. (I mean, everything slowed down, and it all sped up again when I uninstalled the package.) I'm looking forward to revisiting this when Emacs 31 comes out, though.
I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.
As a Vim user (just admitting to my ignorance here), is it not feasible to make something like this yourself? Emacs is said to be flexible and extensible enough, or at least I’m under the impression that it has that reputation.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).
I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)
This is how I justify not switching back to vanilla, despite not really being an evil user. Doom's module system is really great for organizing a config.
Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.
Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.
Ask Claude to reprogram the Emacs graphics display engine to provide 3D wireframe object relations to see Popper's World abstraction navigating World 3 to 1 and backup.
> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
IDEs exist to allow teams or entire divisions to hit the ground running with development, with a standard interface that everybody on the same team uses (a huge boon for collaboration), without a lot of time spent configuring or integrating the tools. All the integration is done by the vendor, often better than you can do it; the debugger integration in full-fat Visual Studio is still second to none.
Grooming a personal .emacs or .vimrc is fine if you're working alone, but when you're on a team of professionals working on an application built on a commercial platform, a standard workflow for development is essential and an IDE supplies all the tools, integrations, and conventions to cover the basics of such a standard. Do not underestimate their value.
I don’t mind IDE per se, Just like I don’t mind Game Consoles. It can be truly useful, as you say, to have something Plug-and-Play to hit the ground running.
But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.
Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.
Bedrock Emacs is pretty much this, its what I finally used after I declared config-bankruptcy with Doom, and it gave me the room I needed to get my own setup together
Reading Rahul's post I got excited to build Emacs 31 from source, but reality occurred and I decided to wait for the release. I also like his articles on setting up Emacs.
I don't care what tools other developers use but in January I made my two dev Macs 'VSCode free' and use Emacs for everything. Feels better!
For decades I would spend tons of time experimenting with my Emacs setups but in the last few years I have been shifting to more out of the box experiences. I did write my own agentic coding platform in Emacs Lisp but I keep that separate from .emacs and .emacs.d
The bulk of the Mastering Emacs blog is a decade old at this point, but its philosophy and the information it provides is still very relevant for any graybeard wanting to get up to date.
I'm a pretty conservative emacs user, partly because I don't want to spend time tinkering to get things to work consistently across Windows, ubuntu, and mac os -- all of which I use daily. My most "modern" adoption is probably using lsp and eglot with various language modes, notably golang and rust.
Should I consider adding tree-sitter into the mix?
Nah. It's great that they're making it less of a hassle to use, but it's still going to be more of a hassle than just using the plain regex-based modes, and treesitter in itself doesn't really make much of an improvement if you already have working syntax highlighting for some mode.
The main exception is if you want to program in a language that only has a treesitter-mode, or I suppose if the regular mode has quite buggy syntax highlighting / the ts-mode has much better features.
(There are also fancy minor mode packages like combobulate that make special use of treesitter, but that's tinkering territory.)
Wow, auto install treesitter grammars, editable xref, transposing window layouts, speed bar as a side window in frame, I had no idea any of these things were coming and were all some passing thoughts I’ve had in the last few weeks “it would be cool if this was supported OOTB”. Some dreams do come true!
> kill-region-dwim fixes a decades-old papercut. Set it to 'emacs-word and hitting C-w with no active region kills a word backwards instead of signalling an error.
back in 2nd year of university I remember thinking that vim is complicated so i went with Emacs. Now after using vim for couple years , I can't imagine going to Emacs and learning it. The availability of vim emulation in majority of text editors and IDEs has been a lifesaver
although the brief time I used Magit I was enamored I gotta say. I tried lazygit recently and it evoked the same feeling I had when trying Magit for the first time
Excellent news! But what are the odds that “treesit-auto-install-grammar” is going to work on Windows? Finding precompiled grammars is so annoying. Windows support would be fantastic, and im hoping these improvements come to eglot next.
Very cool! Looking forward to try out the xref and markdown features. The latter becomes increasingly important since the developer community at large seems to disagree with org-mode being the superior syntax...
I recently sifted through a bunch of tagged entries in a text file, where each entry had a json array of image names, but the images resided on a remote server. I basically wanted a program that could detect if the cursor was on an image name, and display it on the right.
There's a bajillion ways to do this, some might even involve writing an html file and launching a remote server and tunneling and using a browser and what not. But no! ChatGPT wrote 20 lines of elisp code. I add a tramp basepath, open the text file, and got exactly what I needed. Need any behavior changes, callbacks, transformations? Modify, eval expression, new behavior!
I asked ChatGPT what other system I can use to achieve the same effect. The best answer it gave was neovim. No, neovim can't do that with the same degree of ease.
Disappointing and amazing at the same time.
The drawback of the emacs approach in my case is the tramp latency. To speed things up we'd want to add prefetch and that's gonna be much more than 20 lines and C-x e
Agent-shell.el for the CLI experience that's integrated with emacs. You can send things from emacs to your Claude code prompt and it will include the file and line numbers.
There's also claude-code-ide.el that gives you more of a cursor like experience with autocomplete, simple chat, etc.
claude-code-ide runs the claude TUI inside a term inside emacs with a little bit of editor integration on top. It's closer to the standard CLI experience than agent-shell is.
I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.
Emacs is more than a dev environment for coders. Some of us here use it for everything that can possibly be represented in text form: our TODO lists, our calendar, our RSS reader, our mail reader, etc. Me, I even maintain billing spreadsheets for a side business as Org-Mode tables. New features in the latest Emacs releases, and in successive releases of individual packages, have brought some nice improvements in those areas.
I am always a little bit puzzled with the versions. I use Emacs from Snap on Ubuntu.
I have to use the pgtk channel, because Wayland.
pgtk/stable is 30.2, pgtk/edge is 32.0.50. Version 31 is not even offered on snap, in none of the channels. I am running on edge (32.0.50) with no problems.
I use emacs --daemon instead of tmux inside my agent sandbox for session permanence and portability. A full editor rather than a layer between me and my editor. I can even waypipe the client windows if I want mouse support.
I do the dinosaur version of this, with screen and xpra. Works great. CC and codex being terminal-native may make terminal-based (or at least terminal-comfortable) editors seem more natural to a broader set of people.
Why use screen? Just leave your emacs --daemon running, and when you reconnect, run emacsclient and all your buffers are back. And you only have to learn one method for arranging frames rather than both emacs' and screen's.
There is a superior, faster and more efficient alternative just at your fingertips waiting to unleash its magnificent power if you would only dare to dream big.
Have they fixed MacOS startup performance yet? ISTR some post about why faster CPUs were making emacs even slower on startup. Seems to have gotten worse over the years.
emacs -nw takes about 2 seconds on my mac. I don't use server/daemon, and those 2 seconds are processing my startup elisp files (it's ready nearly instantly without prepping my junk).
It's so refreshing to see emacs just sticking to its guns and getting solidly, steadily better over the years. Inspirational, even. This is how software should be. Can't wait for all the tree-sitter improvements!
I’m curious as to why - is it a matter of stability/feature completeness in 30.2 that you don’t need or want to bother with new releases? Or that you don’t like the direction of the project past that point?
The issue was traced to library xinput2, when compiled with '--without-xinput2' the issue does not occur. But I do not know if that is something that Emacs can address.
> If you've ever built a three-window layout and then wished the editor pane were on the other side, these do the job and keep every buffer in place while they're at it.
I built a tmux like buffer manager. So I can just pick a window, press Alt-F#, and switch that pane over to whatever buffer I want. It's super easy to even display the same buffer twice but in different panes.
If you're using one without the other you're going to have a bad time.
If I want to change layouts I just close panes down to one and then open it up in the configuration I like. Then I just switch to each pane and Alt-F# the correct content into it.
It's nice to hear the emacs terminal emulator has gotten some love, after all the controversy about the nasty language that used to be in its source code, which rms moved out to a separate file after somebody complained.
Open source with profanity in comments is statistically better than code without it:
DonHopkins on July 6, 2023 | parent | context | favorite | on: Open source code with profanity in comments is sta...
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
;; disgusting unix-required shit
;; Are we living twenty years in the past yet?
(defun te-losing-unix ()
nil)
[...]
;; (A version of the following comment which might be distractingly offensive
;; to some readers has been moved to term-nasty.el.)
;; unix lacks ITS-style tty control...
(defun te-process-output (preemptable)
;;>> There seems no good reason to ever disallow preemption
(setq preemptable t)
[...]
;; I suppose if I split the guts of this out into a separate
;; function we could trivially emulate different terminals
;; Who cares in any case? (Apart from stupid losers using rlogin)
[...]
(?\C-b . te-backward-char)
;; should be C-d, but un*x
;; pty's won't send \004 through!
;; Can you believe this?
[...]
;; Did I ask to be sent these characters?
;; I don't remember doing so, either.
;; (Perhaps some operating system or
;; other is completely incompetent...)
[...]
;;-- Not-widely-known (ie nonstandard) flags, which mean
;; o writing in the last column of the last line
;; doesn't cause idiotic scrolling, and
;; o don't use idiotische c-s/c-q sogenannte
;; ``flow control'' auf keinen Fall.
"LP:NF:"
;;-- For stupid or obsolete programs
"ic=^p_!:dc=^pd!:al=^p^o!:dl=^p^k!:ho=^p= :"
;;-- For disgusting programs.
;; (VI? What losers need these, I wonder?)
"im=:ei=:dm=:ed=:mi:do=^p^j:nl=^p^j:bs:")))
[...]
(setq te-process
(start-process "terminal-emulator" (current-buffer)
"/bin/sh" "-c"
;; Yuck!!! Start a shell to set some terminal
;; control characteristics. Then start the
;; "env" program to setup the terminal type
;; Then finally start the program we wanted.
(format "%s; exec %s"
te-stty-string
(mapconcat 'te-quote-arg-for-sh
(cons program args) " ")))))
;;; term-nasty.el --- Damned Things from terminfo.el
;;; This file is in the public domain, and was written by Stallman and Mlynarik
;;; Commentary:
;; Some people used to be bothered by the following comments that were
;; found in terminal.el. We decided they were distracting, and that it
;; was better not to have them there. On the other hand, we didn't want
;; to appear to be giving in to the pressure to censor obscenity that
;; currently threatens freedom of speech and of the press in the US.
;; So we decided to put the comments here.
;;; Code:
These comments were removed from te-losing-unix.
;(what lossage)
;(message "fucking-unix: %d" char)
This was before te-process-output.
;; fucking unix has -such- braindamaged lack of tty control...
And about the need to handle output characters such as C-m, C-g, C-h
and C-i even though the termcap doesn't say they may be used:
;fuck me harder
;again and again!
;wa12id!!
;(spiked)
;;; term-nasty.el ends here
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
What’s the appeal of an editor like Emacs in 2026? Why’d anyone still use when most jobs nowadays require you to work inside a container (and therefore use VSCode container extension)?
Can't you ssh into them? If so, in emacs you can just open /ssh:host:path/to/file and remotely edit that file.
Even if you didn't have emacs, I don't think you are forced to use VSCode. You could just use sshfs and use any local editor, but I guess other editors also have remote editing plugins
"Is anyone still using emacs?"
Yes, 34 years and no plans to switch.
Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CLI much much convenient and faster than moving hand to reach cursor keys.
My only gripe is that Firefox and its derivatives it doesn't work any more. Long time ago it did work. And I have no idea why feature was dropped some rewrite.
e: s/deadline/readline/g
> "Is anyone still using emacs?"
Nothing else is capable of handling the variety of text-related things I want from my text editor.
- I consume HN and Reddit in Emacs. Allows me for example to quickly search through all the links shared in a thread.
- I read Jira and Slack in Emacs - in org-mode. It is far better for finding relevant things, extract them for my notes, etc.
- All my writing done in Emacs. Because I have: spellchecking, thesaurus, etymology and definition lookup, translations, LLM integration, etc. All my notes are in Org (Zettelkasten style).
- All my spaced repetition cards are in Org-mode (they are parts of my notes, I don't need a separate system to manage them). I can generate number of cards to study a topic, from selected notes.
- All my AI sessions are in Emacs. It's amazing that I can send just about any text to an LLM, anytime, anywhere. I can do it in the middle of typing a message, like this very comment.
- I watch YT vids controlling the playback directly. I can pause, rewind, speed-up, mute, extract transcript, etc. - this is indispensable while watching and taking notes.
- my email client is in Emacs (of course, why not)
- my Telegram client is in Emacs. I can easily retrieve a video from any web page and send it directly (without linking the page).
- I can extract any part of my screen and OCR the text out - it pops up in an Emacs buffer.
- I perform all searches from Emacs - I can google, duckduckgo, brave, HN (algolia), wikipedia, etc. I search through my browser history in Emacs.
- I can control my browser tabs, switch between them, find matching lines on the page, jump to links, etc.
- I read and annotate PDFs in Emacs.
- And I haven't even touched anything programming-related (tons of things)
Why, oh why would I ever feel unsatisfied, hoping that there's anything else that can help me do things better? Honestly, there just doesn't exist a piece of software that could help me do even a subset of things I can easily achieve with Emacs. You'd ask me that question in 20 years, if I'm alive and still using a computer - the answer would be - "Yes, what else would I use?"
> - I consume HN and Reddit in Emacs.
What are you using for Reddit now that they have closed access to their API?
I'm currently using my custom fork of thanhvg/emacs-reddigg. It isn't ideal, I've been itching to rebuild it into something more robust. Well, one day I may get annoyed enough and just do it.
I wish I could reach this level! maybe one day... except in neovim ;p
I use Neovim too, but it never can fully replace Emacs for me. https://news.ycombinator.com/item?id=48589770
Nearly 40 years for me. Wow! I’d note that MacOS input fields also have basic Emacs bindings for cursor movement, not just shells and browsers. Works in MacOS Mail, Evernote, etc.
43 years for me. Started in 1983 using Gosmacs on a black-and-white CRT terminal. Gosling too was frequently in the terminal room.
Yes, emacs keystrokes became kind of cli lingua franca, which apparently many do not know. I don't remember my self ever read about those supported explicitly anywhere, but accidentally I found out long time ago and then whenever I try new systems, programs and whatever I try which keystrokes do work. Quite often at least some work.
It's GNU Readline[0] or similar. It's all over the place, on Linux at least. Being GNU it defaults to emacs, but the vi support is also excellent. The first thing I type in any foreign bash is 'set -o vi'.
[0] - https://en.wikipedia.org/wiki/GNU_Readline
Yes it's GNU readline, but note that the very Wikipedia link you gave explains that it's GNU readline that re-used those shortcuts from Emacs, not the other way round.
So it's not wrong to call these "Emacs" shortcuts.
Well, it is called `set -o emacs` in all shells of note (except POSIX; even pdksh).
It annoys me so much to have learned that GTK text fields used to have an Emacs editing mode, which they've hidden behind an unaccessible configuration option, and now it's hopelessly broken in modern GTK version.
I spent a day or so hacking around with kanata[0], which is a kernel level keyboard remapping tool, that lets you define[1] keyboard mapping layers in a similar way you might with QMK firmware. When I hit the control or meta/alt/option key, it activates a layer where Emacs editing keys are emulated using the GTK equivalents. For example, C-a and C-e are mapped to home/end, etc. I preserve my macOS CMD-not-control-key muscle memory this way too.
The only problem is, this is not the behavior I want in terminals or in GNU/Emacs itself. I wrote a small python daemon (managed by a systemd user service) which wakes up whenever the active window changes. Based on this info, I send a message to the TCP server that kanata (also managed by a systemd user service) provides for remote control to switch to the appropriate layer.
[0]: https://github.com/jtroo/kanata
[1]: https://gitlab.com/spudlyo/dotfiles/-/blob/master/kanata/.co...
This is so cool. Thank you!
Wow, so you used the earliest public versions. Ever written a retrospective of what 40 years of Emacs has been like?
Nope. And I’m probably not a great person to write it. I’m hardly an Emacs power user. I had friends who would do everything in Emacs to the point where I would joke with them that Linux was just their Emacs boot loader. I keep lots of other apps and term windows open. My init.el file is pretty simple. I’m often aware of a vague capability that Emacs has, but I’ll brute-force my way through an editing task with keystrokes and some keyboard macros rather than add a new fancy library, at least until I’ve been forced to do the same thing a couple times per month. That said, I do remember trying to use Emacs on a 300 baud dial-up link. That was painful, though truthfully everything beyond ed would be painful at that speed.
Similar usage pattern (no init.el), but I started with TECO Emacs in the late 70s.
I'm curious... why are people (this thread, but there are several independent others) replying to "Is anyone still using emacs?" ? I don't see that sentence anywhere in the article!
It's an article about emacs so I guess people were curious enough to ask that question.
Sure, and I'm not arguing that the answers are uninteresting, but I found it odd that this is being double-quoted several times as if it was taken out of the article.
I believe it's a response to something posted recently, but I don't know what.
> Yes, 34 years and no plans to switch.
It's 26 years for me. Emacs is I believe the oldest software I still use. I started on an SGI Irix in 2000. I used it also on HP-UX, Solaris, Windows, MacOS, and of course all varieties of Linux
> Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
And many keystrokes work on MacOS, too. That was a pleasant surprise when I got a Mac laptop for work.
It's quite difficult to find software older than Emacs in widespread use. Emacs is one of the "original" software, the first GNU software for which the GPL was created. It competes with vi, whose direct lineage has been broken (nvi and vim are reimplementations).
> It's quite difficult to find software older than Emacs in widespread use.
Agredd! Aside from the basic Unix commands (ls, cat, etc), the only substantial program that I use today that I also used in 1991, is emacs.
Well, and perl. I don't write much perl these days, but I have tons of perl scripts accumulated over the decades that I use daily so that counts as using it.
Third oldest for me would be mutt, which is still my primary email client. But I only switched from elm to mutt in.. not sure maybe 1996?
vi recently received an update. C23 compliance and some unicode fixes. it's a feature complete editor!
One advantage of vi is that even though emacs is available on all those systems, vi is actually installed on all of those, setting aside windows. If you know rudimentary vi you can walk up to any of those machines and edit a configuration file well enough to work.
vi isn't even in the same neighborhood in this regard. You can and should learn vi (and ed!) in one afternoon even if you never use them. Whereas Emacs isn't something you just learn in an afternoon. (And vim is not the same as vi)
That is a separate discussion from whether you should use ed or vi normally. You learn the "fallback" with the hope of never being forced to used them.
mg is installed on macOS by default and is basically diet vanilla emacs. Works fine for quick edits.
Why is anyone using anything else?
I don't like keyboard-centric text editing. Yes GNU Emacs supports the mouse, but just like Vim the experience is miserable. You can spend a lot of time configuring it, but at some point you're just writing extensions of extensions just to get a basic GUI flow that isn't painful, and no matter what it'll never feel quite "right". The program just wasn't built with the idea of a mouse in mind, and bolting it on really wasn't sufficient.
Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.
I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.
> I don't like keyboard-centric text editing.
Interesting? Unless you're using voice dictation, isn't text editing 100% keyboard based input?
No. Even most keyboard-centric text editors implement mouse inputs, with only a few exceptions coming to mind, almost none of which anybody uses today, for example ed. In fact, most editors don't even restrict text insertion and deletion to keyboard input, which is what you might be confusing with "text editing", which might be more clearly expanded to "operating a text editor".
Likely because they haven't seen the light just yet. Or they are lost to the evil forces.
The only reason why I was taught vim is that a coworker wanted someone to know it so they can explain why emacs is better. It didn't work and I've transitioned to neovim.
I use Lem. It's an "emacs" but not a clone of GNU Emacs. It's written in Common Lisp, extensible in Common Lisp and it's way more performant than GNU Emacs. Obviously less features and plugins but for my needs (writing Lisp code mostly) it's great.
How is it now compared to 6 months ago? I tried it back then, and just... I don't know, couldn't get into it.
Dunno, I've been trying it off and on since it was first released in like 2018. I don't theres any particularly noticeable changes from 6 months ago specifically.
I also used Emacs way back in the day but have been Vim/Neovim for the last 5 years or so. But I recently started a new Lisp project so revisited Lem, actually set it up the way I want (with LazyVim-like bindings), and found with my changes and comfort hacking on it (it's all Common Lisp top to bottom so it's easy to change) that it can replace LazyVim for me now. Just using the ncurses front end BTW.
I use vi because I'm not a savage
I'm a die-hard vimmer. I use vim-motions everywhere - they permeate my editors/IDEs, browsers, terminal, I use them system wide (e.g. to change volume or control media or my WM). One day I woke up with the realization of the fundamental truth - Emacs simply vims better. Much better than even Neovim. I just had to master Vim and grok some Lisp to arrive to that conclusion.
People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.
Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.
If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.
Almost all my vimming is in Emacs now. I started with Org mode - now I can't find any feature of any TODO application that Org mode doesn't do better.
I'm heading towards that point. org-mode is just too good as a todo & notetaking app. Just not vimming in my emacs yet.
Timezones?
Org timestamps infamously do not support them.
I can't imagine using a todo application which lies to me half a year and every time I travel.
> Org timestamps infamously do not support them.
So? Emacs has built-in solar and lunar calendars, has world-clock command, format-time-string accepts ZONE argument. Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones? This can be done in less than 15 minutes. With AI maybe in 20.
You're not dealing with an app you paid for, and your complaint not even an accurate one: Org's timestamp format doesn't encode timezone by default. Emacs absolutely supports the feature you want, you just didn't know about it.
Oh, you can't imagine how I'd like to be proven wrong.
Last time I checked, proper timezone support wasn't there. One could specify single timezone for entire org engine, but not per timestamp. I found some nearly official mailing list thread where participants couldn't settle on a single solution, and so the conclusion was that proper TZ is not coming to org.
> Org's timestamp format doesn't encode timezone by default
> format-time-string accepts ZONE argument
Isn't format-time-string just a visual decoration? Last time I checked, agenda and all other plumbing always treated every timestamp as local (to the TZ configured globally). And so if I recorded that I have a meeting at 1PM London time, my org-agend would show it to me 1PM even if my TZ is set to New York.
> Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones?
Can you elaborate? My understanding was that I'd need to rewrite entire org in order to support time stamps with mixed time zones embedded in them.
> You're not dealing with an app you paid for
Actually, I'd be willing to pay above the competitor _subscritpion_ price for an org-based organizer with
- proper TZ support
- conflict-free sync between devices
- (cherry on top) touch UI friendly Android client. But honestly, orgzly would do, as long as it supports the above
So the problem is two-fold, right?
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.
Aren't Org mode dates ISO 8601? ISO 8601 has an optional timezone, is that not supported in Org mode? You could then use format-time-string to configure how it is displayed.
Another possible solution. Often - but not always - a datetime and timezone pair can alternatively be represented as a UNIX timestamp. Depending on the use case there are tons of ways to manipulate UNIX timestamps, and Org mode might support that naively (I'm not sure, try it).
Thanks for the detailed explanation, I really appreciate it!
Functional and comfortable syncing with your mobile?
I suppose that you mean via some third party cloud. I personally sync my Org mode notes via adb when I backup the phone occasionally. I read on the phone using Orgro.
You might be able to sync with Dropbox.
If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!
"If emacs is not installed on a system, I use sed."
Bill Joy (creator of vi) once said that if he sits down on a foreign system, he reaches for ed [1].
To be fair, both emacs and vi have "magic exit incantations", though if you have emacs perhaps you have a menu in GUI mode. If not, C-x C-c is really not any more memorable than :wq! The vi one at least has an obvious mnemonic ("write quit") but either way, you need to know an arbitrary sequence of keystrokes.
[1] http://xahlee.info/comp/interview_with_bill_joy.html
NeoVim because it's fun!! So many plugins and colorschemes!
So customizable- these days Claude will just change it for you, no need to learn the APIs if you're just interested in the result. Yes you're AI-slopping your config, but the drawbacks to that are super low (it's a personal editor, not something I'm inflicting on others)
AI slopping my config is what allowed me to learn vim without going through the pain of setting it up. I can ask AI to teach me about some motions or set up some configs for m in lua without ever know lua. This is the biggest impact of AI in my professional life.
Vi is fine. It's superior and to bare ed - The Standard Editor*, when you don't have anything else available. I made much of my living coding vi 7 years in -80's. And I still use vi, when emacs is not there or system has so little memory that emacs is too much. Which is usually with a embedded systems or some old Unix on single mode fixing unbootable system.
*) https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
You will be downvoted into oblivion.
For speaking the truth.
Vi-lets, engage!
why do we run from the police dad? they use emacs, we use vi, son.
For Firefox I've switched to Glide (Firefox fork?) and configured it to implement Emacs keybindings. There is a config on the project's Github discussions page that I started off of.
> Emacs cursor movement keystrokes are quite widely supported elsewhere too
Yes, even in Codex and Claude Code.
> Those work well also besides shells with Chromium/Chrome/Safari... My only gripe is that Firefox and its derivatives it doesn't work any more
Interesting, my experience is exactly the opposite: I had to finally bite the bullet and migrate to Firefox because Chrome/ium switched to GTK4 which removed key themes support.
(That's OK though, I should've moved off Chrome a long time ago.)
There are so many fad technologies out there, but vim/emacs and unix command line in general are skills you can invest in that stay relevant for 40+ years.
I wish Emacs LISP gained ergonomic static typing. I always find working in un-typed languages very hard.
Weell, it's not completely untyped, but it is runtime type-checked. There's stuff like `(if (integerp foo)` and `(defcustom ... :type '(choice (const tag "abs" abs) 'integer))`
And then there are more ambitious projects like the static analyzer and language server https://github.com/emacs-elsa/Elsa I haven't tried Elsa yet since it seems to require setting up a package manager like Eask (I don't really understand why I have to install a package manager to run a language server, especially when they support four emacs-specific package managers?) and the docs were very light on whether eglot is supported or just lsp-mode.
> GNU deadline
I think you mean readline?
Sure. Browser autocorrect there just tried to be helpful :/
That said, I'm kinda hoping somebody does create a "GNU deadline" project now. I'm curious to see what kind of project it would be.
A weird, inscrutable project management tool for the shell written in Perl 4 and Guile Scheme, that the ten people in the world who learned to operate it swear it is the greatest piece of productivity software ever invented.
Notable users: GNU HURD Project (Shipping any day now).
I thought you were using emacs?
Well, I've got to admit I've haven't read HN using emacs. Is there such a .el thing avalabnle somewhere? It would be great to read HN as it was with usenet news. Not joking, that would be excellent tools I'd like to have !
There’s https://github.com/thanhvg/emacs-hnreader, but it doesn’t appear to support commenting.
Why not use eww?
I started with gosmacs then switched to gnu emacs in 1985ish. So about 40 years. The renaissance of emacs development in the last decade has been very nice to see.
Firefox emacs bindings still work on Mac since everywhere on macOS supports emacs bindings, nearly.
I just tried, and my macOS up todateFirefox (still Sonoma few weeks), doesn't work. Nor does Waterfox (Firefox derivativ) that I've been using more lately. Could it be some setting I need to set before it works?
Unless I misunderstood your question, are you simply trying to use emacs bindings in all text areas of the browser like the URL bar, any text fields on webpages, being able to move to the beginning or the end of a line, backspace, etc., go to the next or previous line, all with emacs bindings? That has worked for decades on Mac and it works for me now in all browsers.
Idk, its never stopped working for me for the past 10+ years. And Firefox has additionally always supported ctrl-n and ctrl-p working in the address bar for suggestions while Chrome has never supported this
45 years for me. I don't even think about keystrokes anymore.
> "Is anyone still using emacs?"
I have never used emacs seriously as an editor, however, I couldn't work without magit. I even manually build emacs 28 so I can re-use the same set of magit configure files.
> "Is anyone still using emacs?"
Answering to preemptively asked question that doesn't appear in TFA: yup I sure still do.
If anything compared to the 486 days, back when Eight Megabytes And Constantly Swapping was a joke that made sense, my computer now instead of 8 MB or RAM has 32 GB or RAM (so 4096x more RAM, or 2 exp 12 more RAM: something something about transistors doubling every 18 months and all that)...
Who's laughing now? ; )
Seriously though: Emacs with native-compilation, tree-sitter and LSP support (and stuff like Magit and ripgrep integration too) makes it really amazing.
Yeah, emacs is very competitive with "modern" IDEs. Even in JVM languages, which for a long time wasn't true. And I don't know of anything, anywhere that can rival magit.
I've been using it for far less time than you have, began ca. 2011 or 2012 here[0], but over that time it has been my constant benchmark for what an editor should feel like, and every other IDE I've used has fallen short. With LSP especially, in the past 6-7yr I have actually been predominantly using emacs. Part of that was being fortunate enough to no longer have to work on much JVM stuff since ca. 2019, but it's also due largely to large advancements in emacs' capabilities.
[0] https://groups.csail.mit.edu/mac/users/gjs/6946/mechanics-sy...
EDIT: In particular, this is exactly where I fell down the rabbit hole:
> If you are not familiar with Emacs you SHOULD run the tutorial, which can be accessed in edwin by holding down the control key and typing h, then, releasing the control key, type t. (C-h t)
I don't know if there's anything else on the entire internet I can specifically point to that has had a greater impact on my professional life... strange.
Emacs keystrokes don't work in the textarea I'm using to write this comment in Google Chrome.
Specifically none of these do anything like what they do in Emacs: C-a, C-e, C-n, C-p, C-f and C-b.
This is on Linux, but ISTR finding the same state of affairs on MacOS many years ago during some previous iteration of this conversation.
They also don't work in VSCode.
Those keybindings work on MacOS for me, but not on Linux (by default).
There is a way to enable Emacs keybindings in all GTK apps on Linux, but it’s quite buggy in practice (many apps define keybindings that override or conflict with these), and I believe the feature is officially deprecated.
"On MacOS" is not specific enough. Do they work in a textarea in Google Chrome on MacOS?
In vscode on MacOS?
Yes. For me, on all MacOS versions from Catalina to Sequoia, the basic Emacs keybindings listed here work almost* throughout the operating system: https://support.apple.com/en-us/102650
I don’t daily drive VSCode but I use it for teaching, and then basic Emacs keybindings like C-n and C-a and C-k work pretty much everywhere, from the command palette to the code editor, without any plugins.
I also don’t use Chrome as my daily driver, but keybindings like C-a/C-e certainly work in both text areas and address field, or I would have remembered it as one of the annoying exceptions. I do regularly use a few Electron apps, which are based on Chrome, and it does work fine there.
*: There are a few apps that deliberately break the Emacs keybindings. Microsoft Office is one of them, since they insist that Ctrl keybindings on Mac should do the same as it does on Windows, which is extremely jarring if you rely on the Emacs keybindings everywhere else.
Yes. Basic emacs keybindings work pretty much everywhere in macOS. I have run into a couple of apps that don’t behave correctly, but 99% of the time they work.
And you've tested this in a textarea in Chrome or in vscode?
I am typing this in a textarea in Chrome, and the basic Emacs navigation commands all work: C-a, C-b, C-e, C-f, C-n and C-p. (The M- equivalents don't, though. You just get some special chars: å, ∫, ´, ƒ, ñ (dead char for the accent), π.)
Chrome Version 149.0.7827.155 (Official Build) (arm64)
Very similar in Visual Studio Code.
(I started using macOS in 2010, I think, and the Emacs-style shortcuts have felt pretty well supported the whole time. I can't promise that applies to Chrome as well though, as I'm not a regular user.)
I have been using VSCode for teaching the last few years, and routinely use a VSCode without plugins for that purpose, and Emacs keybindings work fine in its text area (the code editor itself). If it doesn’t work for you, then apparently something is broken on your computer. Not all keybindings work but the ones listed under Text Editing here certainly works for everyone else: https://support.apple.com/en-us/102650
"Is anyone still using emacs?"
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)
Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
Plus a bunch of other things!
Just to expand a bit on "bunch of other things". You can see a vterm vs eat feature comparison here: https://dakra.github.io/ghostel/#ghostel-vs-vterm
Besides the performance and what baokaola already mentioned some things that make Ghostel better than vterm especially when working with those cli agents are:
- proper handling of resizing windows
- progress reports (you get a spinner in the modeline when claude thinks)
- notifications (get an alert when your agent is done)
- drag and drop works
- hyperlinks. urls and files are clickable
I love ghostel. Thanks for making it.
And Ghostel support recently landed in claude-code-ide.el!
I don't understand what this means. How does claude-code-ide support or need a terminal like ghostel?
https://news.ycombinator.com/item?id=48585950
claude-code-ide.el works by running the claude tui inside a terminal inside emacs and then connecting to that claude via the model-context-protocol.
cf agent-shell which uses the agent-connection-protocol and provides its own interface.
Is it conservative in what it sends, and liberal in what it accepts?
Can you elaborate a bit on what you are asking about?
The name Ghostel sounds like a tribute to the Ghost of John Postel, whose law is a good thing for a terminal emulator to respect:
https://lawsofux.com/postels-law/
https://en.wikipedia.org/wiki/Robustness_principle
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
Lol this looks like a wonderful coincidence.
I thought it was named Ghostel because of Ghostty and EL (emacs lisp).
> I thought it was named Ghostel because of Ghostty and EL (emacs lisp).
It was. But I like the Postels law relation as well :)
This got downvoted, but it made me laugh.
"Is anyone still using emacs?"
Of course. Emacs has been my stable editor over many years, handling many languages that came along, surviving many other IDEs that came and gone (the latest being the Cursor sold out).
There're always new enhancements in Emacs, from multiple-cursor editing years ago, to LSP and tree sitter in recent years. Currently I just got into the vertico/marginalia/consult/embark combo packages. Embark with its context based actions seriously is an amazing underrated package.
I also have been using emacs for almost anything for the past 20 years. I had to switch to VSCode for coding over a remote ssh connection to cloud VMs. The client/server split of vscode felt superior over the ssh connection and the emacs alternatives was not up to the same level of performance two years ago. Do you know any progress on that front? I would love to go back to emacs as my daily driver but I am sensitive to lags when I type / execute commands. Have you worked with ai assistants over a remote connection?
The two complaints I hear is:
1.Memorizing how to use it has a big learning curve.
2.Wrist pain from pressing button combinations all the time.
Otherwise plenty of people still use it and it's great. Just hard to pick up for new users.
I've only ever used emacs in vim mode (evil-mode). Its vim emulation is the best I've seen anywhere.
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
[1] "Evil Software Hoarder Emacs": https://news.ycombinator.com/item?id=26113192
I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.
Yup. I've aliased it to e and and it works just fine. Sort of "send file into Emacs". I've also added some elisp to say things like e something.c:43 so that it opens it up at line 43.
I used have a ep which I could pipe something into and it would put it in Emacs buffer but that stopped working somewhere I never got around to fixing it.
I used emacs for about 16 years, but never properly gotten into client-daemon setup. What’s your setup? Does the daemon preserve open buffers and stuff, so when you connect you have all your openned stuff? Or each emacs sessions have separate set of buffers and windows?
> Does the daemon preserve open buffers and stuff, so when you connect you have all your openned stuff?
Yes. I use it instead of tmux for that.
Yes to some extent. When you attach to it, the default screen will still be scratch, but all your buffers are still open. There are some settings you can set to fix that, if it's burdensome.
Emacs --daemon once and then attach to it with emacsclient.
WRT point 2, binding the caps-lock key to ctrl helps a lot, or finding a keyboard with the ctrl key to the left of "A".
being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example
On my MacBook I map the right hand command key to “ctrl” and the right hand option key to “meta”. Since the command keys are right next to the space bar that puts the ctrl key on a thumb position most of the time, and for the times when that isn’t a good key for a given combo I still have caps lock bound to “ctrl” as well. Seems to work reasonably well and lets me keep the usual command and option keys on the left side for “super” modifiers and for typing accented and other characters.
For my desktops, I use an Ergodox EZ keyboard and mapped ctrl and meta into the thumb clusters there.
Use Spacemacs? What I was recommended by a power user is doom emacs Uses the space bar by default
I don't use actual vim for much, most of my time is spent in JetBrains IDEs and sometimes Xcode. Both with vim emulation. Setting up Spacemacs would take hours of my time for questionable gain. If I was still a student I'd jump on it but alas
Don't use your pinkie or any finger. Use the meat of your hand to hit the control key.
This works especially well on an IBM Model M because there's nothing in the vicinity of either the left or right ctrl, you just chop your palm down and can't go wrong. I could also pretty reliably M-x in one hit by flipping my left hand over, curling my pinkie finger, and hitting the keys with the knuckles. On more crowded keyboards I remap ctrl:nocaps and use thumb and forefinger for M-x. I actually deliberately got rid of my Model M to teach myself to do it this objectively worse way, because context switching between my docked workstation setup and laptop keyboard on the go was difficult. If only someone would make a laptop with a proper keyboard...
> for getting huge swathes of code on your screen at once
This is my major gripe at most IDEs. Every window, or view, or sub-view insists on shaving off a little bit of vertical and horizontal space for... I don't know, tabs or things? Or to tell me what program I'm running?
I just want a dark screen with text (I run Vim, so I'll concede I allow a tiny bit of vertical space for line numbers and a little bit of horizontal space for the command space)
Why not use agent-shell? It makes the whole experience great.
Also claude-code-ide.el. try these
I use claude-code.
I've been trying to use agent-shell with OpenCode but the abstraction that agent-shell puts on top of it is too much. I can't figure out how to change the model. The command to do it doesn't do anything; I see the correct model list and seem to be able to select it, but then it doesn't change. If I just run "opencode" in the same directory it comes up configured the way I want. The Claude integration works with that workflow too. Opencode comes up with some baby CPU-only model that I've never heard of, and basically, it outputs syntactically correct English sentences but doesn't seem to do much more than that.
Since I mostly use Claude I haven't fussed with agent-shell much yet.
Also, if a slash command is missing, that's because the model's ACP client doesn't implement it:
https://github.com/xenodium/agent-shell#why-doesnt-agent-she...
When on the agent shell buffer, do C-c C-v with the latest agent-shell to change the model
C-c C-v to change the model or M-x agent-shell-set-session-model
agent-shell is awesome, but Anthropic banning subscription usage via ACP is a killer. I've liked claude-code-ide.el when I've used it, but its lack of concurrent sessions per project has prevented me from fully adopting it. I know, I should be using worktrees, but I still haven't figured out a nice way to get that to work with my docker-compose-based project (though I'm open to suggestions!)
Anthropic scrapped their sdk billing thing
This stuff all looks great, I can't wait to upgrade to 31 and then forget about all of it and just keep using Emacs the same way I have been for the past 20 years, /again/
The post not long ago about how far the built in autocomplete has come got me to trim down a bit of my config. Seeing that treesit stuff is getting folded in, I may make another effort at trimming down.
It is crazy nice how invisible the native compilation became.
Which autocomplete mode? fido-vertical-mode, completion-preview-mode, or something else that I should maybe look into?
I switched from vertico to fido-vertical myself, but still use company for in-buffer completions. I tried corfu and completion-preview several times but didn’t get something I’m happy with from it.
1. Upgrade to Emacs version +1
2. Remove MELPA packages that are now part of Emacs
3. Go to step 1 when new version comes out
I'm glad to see that people are working on emacs, as I use it constantly. That said, I personally don't see myself really using any of the stuff highlighted in this article. I've never really been in to advanced auto-complete or tree-sitter type of functionality. Some tasteful syntax highlighting and indentation support is fine but that's about as far as I go. That, org-mode, and magit is about all I use for coding and text editing. I also use notmuch for email.
LOL. So true!
Except for tree-sitter. That's something I'll be investing time in.
Investing your time how exactly
As a contributor, of course.
Systems like Emacs that are hyper-configurable via a text file seem tailor made for modern LLM's. If you've got a little bit of Emacs experience but bounced off of it because the learning curve was too steep I highly recommend diving back in with your agent. Agents are really good at setting up and maintaining your .emacs/init.el.
Doing this for Neovim at work and it’s so much fun. I justify the slopped config to myself because I want to get work done rather than learn the config of some random Neovim package and how it interacts with the rest of the system.
I can just ask Claude, “make leader / toggle a terminal at the bottom of the screen , and leader t swaps it to the right side” and it’ll just do that. I liked a theme but I wanted it to also change the status line of the focused window, and it just did that for me. I had an issue where the neo tree would freeze for a few seconds, and Claude figured out it was a bad interaction with the git in our toolchain, etc etc.
I have my very own text editor that I customized in plain English! I could’ve learnt spent hours learning Neovim’s style of Lua, researching packages, debugging, etc, but this gets the same stuff done way faster and lets me get to work. This was the biggest thing that kept me going back to either a preconfigured Vim setup like LazyVim or vscode. Definitely recommend.
My .emacs.d has been carefully handcrafted over years. My .vim/.vimrc accreted over the same period, bits copied in, commented out, …
Claude did my neovim in about 45 seconds, with the instruction “make it work like my vimrc but better and using the cool new stuff” and it’s great! Not my daily driver, but serviceable as EDITOR and prettiest of the bunch.
I agree this is great, but I also feel like it's an intermediate step to just asking Claude for whatever file edits you want... and then you don't even need the text editor.
I’ve always used vim/neovim but fell in love with some of the features of emacs (org, magit, lisp). My problem was spending the time to configure it though.
Even with spaceman’s/doom and the amazing documentation it was always still so much work to configure emacs as a newer user. LLMS have made this nearly instant.
This is a bit of a ramble but it’s so amazing having emacs and an LLM now, I don’t even touch vscode anymore and only find myself touching things like IntelliJ when I really need to dig into something with a debugger.
I may have to dive back in. I've been using lazyvim for most of my terminal work now because spacemacs was too much effort to keep running, where-as lazyvim is a git pull and done sort of thing.
Modern LLMs are ok with that, but they do make silly mistakes; and a major problem here is that your init.el stops being your own, if it’s written and maintained by an LLM, you will have no idea what’s going on there. And if you would be reviewing every single line of your init file, then what’s the point
By elapsed time, I use vim to edit my init.el more than for anything else.
That's a skillset any coder in 2026 pretty much has to pick up. If you don't understand the code an LLM writes for you for your day job then you're contaminating your employer's code base with slop. But if you don't use an LLM then you're not as valuable to your employer as you otherwise would be. So most of us need to figure out how to use an LLM and still understand the code.
Using an LLM on init.el is a lot easier than using it in your day job. A 2 line change that you told the LLM to make is easy to internalize.
A programmable editor really is so amazing now. You can have a LLMs whip up anything you can think of in minutes. Ive used neovim for a long time but never really customized it much. Now I’ve got tons of plugins and can add new features on a whim.
I’ve been thinking of trying out emacs because I think the native gui can probably be even more powerful
I agree. It's amazing. I feel like I've got a private Emacs consultant at my elbow.
I know a bunch of people (including me) who decades ago wished they had a private sendmail.cf expert at their elbow, and even a few sendmail.cf experts who were sick and tired of always being asked to help random people with their sendmail.cf file for free.
Maybe there will be a resurgance of terribly obscure totally unique quirky configuration files for all these vibe coded apps, unique enough that they don't appear in the training data, so you have to hire real humans to sit at your elbow and help you!
I came into that after sendmail.m4 got popular. I'm not sure if that's better or worse.
m4 is what makes Gnu Autotools so delightful!
Look, gang! A brand new sentence!
Agree, I put off using org-roam a few times in the past because I couldn’t be bothered to keep my notes in such order. But now I have an agent that set it up and it’s also recording, organizing, and referencing everything.
If you do any kind of serious work, you need a text editor. Emacs is still one of the best around. It's fast. It's configurable. And it's under your control. You won't suddenly find your text editor "upgraded" with tons of new features you never asked for. It's all opt-in.
haha, I definitely wouldn't call my setup fast. But it did get a lot better after Native Compilation and a lot of the major stuff has started async to feel more responsive at least.
> It's fast.
super slow on windows
That's surprising considering it was fast on computers from 30 years ago
The default garbage collection tunables are also from 30 years ago. Adding the GCMH (Garbage Collector Magic Hack) package resolves much of the slowdown, and native compilation covers the remaining gap quite nicely.
Same on macOS. Could be that we are missing some native compilation option though
It’s slow, bloated and packed to the brim with “features” you will never need.
There is Only One. En garde!
>You won't suddenly find your text editor "upgraded" with tons of new features you never asked for.
I never asked for native compilation implemented via the trampoline technique, which increases attack surface (because it causes Emacs to routinely execute files in a known-by-attackers location in my home directory) and makes debugging harder, but I'm stuck with it if I want my Emacs to speak the Wayland protocol (and I do).
Ditto the clumsy bolting-on of lexical scope.
Native compilation is optional as you surely know.
It also has nothing to do with Wayland.
And what's wrong with adding lexical scope!?
I do have some concerns about certain features but the ones listed do work, and work great.
You can't build an Emacs with Wayland (PGTK) support without native comp. ./configure will complain and refuse to do it.
This sounds like a bug! I mean, this makes libgccjit a hard dependency for pgtk which just doesnt make sense
Sigh. Don’t be “that guy.”
> Tree-sitter that just works
Hallelujah and thank you, sweet little baby Jesus. Now I can get rid of this bullshit from my dotfiles:
That's csh, BTW, just like the Founding Fathers intended.I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesitter highlighting and LSP enabled by default. Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point.
This comment shows up on every single emacs thread and for the life of me I can't understand why. It takes one line in a shell to pull down a premade config and if that were to be built on, who would decide what gets put in? I don't think it's worth anyone's time to decide what everyone needs in a premade config.
The problem isn’t so much the difficulty in finding a pre-made config, it’s a combination of:
A) which premade config to choose
B) what half of those settings even do (and do you need them)
C) a lack of “sane” defaults that use the built in abilities
Realistically walking through the article authors “emacs from scratch” config and seeing what can be done with the built in packages and how is hugely instructive but even then you only get that from walking through the config one line at a time and reading “help” documentation for most of it.
At this point emacs is so old that fixing the problem of “sane defaults” is probably near impossible if only for how much it would break existing configs. But it might be a good addition to the tutorial to provide a set of questions and answers (possibly with demonstrations) that allow a new user to generate their own config with some nice defaults. We can assume these days that most new emacs users are coming from some other editors, so asking questions like “do you want auto complete suggestions in an inline drop down like VSCode” could be a perfectly reasonable question and then it could add the correct configuration settings to config for you using just the built in functionality
>if that were to be built on, who would decide what gets put in?
A small number of people with taste and experience.
Like one hopes to be the case for every opinionated preset profile set.
Yes. That's why you should use Doom Emacs.
Doom emacs might as well be a completely different editor—it completely changes the keybindings.
You are just worrying for no good reason. Doom Emacs and Spacemacs are both very good; being far removed from vanilla emacs is not a problem to be worried about.
Both of those are modal editor configs. Which... No thanks?
Same, I use Spacemacs in holy mode, which is spacemacs with normal emacs key bindings and not vi modals, but still I wish there was a good config that was straight up emacs bindings and didn't pull in evil at all.
Both Doom and Spacemacs work fine without the vi bindings.
Doom doesn't, it defaults to vi bindings and you can't turn that off easily. Spacemacs does offer a choice, though.
Last time I looked it appeared to be as simple as disabling evil mode and configuring a new leader key. But you're right, it's not a straight configurable.
Huh? Emacs is inherently a modal editor - transients, isearch, keychords, M-x - these are all forms of modality. Vim-motions simply organizing that all into nice set of patterns - memorable and very practical. Besides, both Doom and Spacemacs absolutely can be used without Evil layer.
This is a ridiculous collapsing of the sense of what people by "modal editing" into a homogeneous conceptual soup.
The core editing components of non-Evil emacs are direct manipulation, not modal. That there are modal aspects on top of that for doing things which practically/genuinely need a modal switch (command entry, search entry, etc) doesn't make the default emacs configuration a "modal editor" in any sense of which people actually apply those terms.
By your definition of modal, almost every application can be described this way. The point is not whether a system has modes, it's whether it makes its core emphasis and interaction modal.
You can see vi's motions as elegant and purposeful. I see them as an accident of history stemming from the poverty of the number of keys and capabilities of the dumb terminal it was designed on.
I encountered both editors in the late 80s and chose emacs precisely because it didn't have the "barely a step up from a teletype" interaction model that vi had.
As for Doom and Spacemacs without Evil.. yes... but why? Their original and state purpose was a packaging with a modal default. It's trivial to toss together your own init.el that brings in the same set of packages these days and with very little effort.
If the goal is an easy packaging of emacs with sensible defaults.. and then you have to go modify the defaults to make it what most people (yes, most) would consider sensible... No, that's not meeting the state use case.
> You can see vi's motions as elegant and purposeful.
Sure I do, and there's so much tacit knowledge that I can't ever explain verbally or in writing that goes into it, to the point that arguments like yours, challenging my "choices" would ever feel less disingenuous. It's like forcing a left-handed kid to hold the pen "correctly", due to religious dogmas. It just works far more naturally for me and thousands of other people, and just because you don't get it, it doesn't make the model useless. Try to see the other side, sometimes "dumb" ideas do work, and shit that works maybe ain't that stupid.
> Doom and Spacemacs without Evil.. yes... but why
Great question. Now maybe you're trying to learn something despite of "years of the opposite experience" feeding to your hubris. Doom offers a set of Lisp macros that come very handy - map!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, etc. - they genuinely can slash the inevitable boilerplate in the config. It's much easier to experiment with advising and instead then writing ad-remove-advice with different syntax, repeating the symbol names, etc., you'd simply prepend `un` to the form and eval it. add-hook! allows binding multiple fns to multiple hooks. And these are just some examples.
Also Doom does some tricks to make the startup blazing fast. Many times I have compared my config (that pulls over 350 packages) with someone else's vanilla. Doom demonstrably starts much faster.
I think it is cultural. It's kinda like building your own lightsaber as a Jedi. The part of Emacs/Vim initiation is building your own configuration that works for you. Setting up plugins, keybindings, colorschemes etc. It's part of the fun of it (at least for me).
Oh yes. What other software allows you so much to make it your own? Yes, I know the yak shaving argument etc. But what's the fun in opening up some computer/OS/software that looks and feels exactly like everyone elses? An Emacs (and vim) setup is something you can actually have a discussion about with someone else.
KDE, various window managers (i3, awesome, xmonad,...), the Linux kernel (there's so much stuff you can configure through sysctl alone, and that's just 1 single customization facility), SystemD, your shell (whether it be bash, zsh, csh, ksh, or something else), and the list goes on.
And then slowly over 20 or so years deleting all of it.
I think I'm down to about 110 lines of ~/.vimrc now :}
But without building it all up and then slowly deleting it, you wouldn't have known which 110 lines were the ones to keep ;)
There's Bedrock, Centaur Emacs, Witchmacs, and more; even if you don't like Doom and Spacemacs there's plenty of fish in the sea. Though there is the issue where preconfigs tend to have edgelord 'Dark As My Soul' themes which make text absolutely unreadable, which is a bit of a pain to deal with.
Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.
It won't be a perfect transition, but it will make it a lot smoother.
Done this exact thing. Fed an agent my actual keybindings and `M-x` history, let it regenerate a lean init.el. Two notes from the other side of it. It's great at the 2% you named, but it silently drops the muscle-memory stuff you never think about: which-key, the half-configured LSP, that one hydra. Diff the old and new against a day of real editing, not against your memory of what you use.
The bigger thing. "Ask the agent to build it" is fine here because init.el is read-only damage. Worst case it writes a file you `git diff` before trusting. That's the safe end of the spectrum. The instinct breaks the moment the same agent is touching things you can't cheaply inspect: package installs, shell-outs in a hook, anything with a side effect off your disk.
The lesson I keep relearning building this stuff: an audit log after the fact tells you what broke, it doesn't stop it. What you actually want is a capability check before the agent acts. This run is allowed to write `~/.config`, not to curl-pipe-sh. Plus a trail you can't quietly rewrite later, a hash chain, not a log file anyone with write access can edit. For an init.el that's overkill. For an agent you'd let near `apt` or your dotfiles repo, it's the whole game.
https://orkia.dev/r/e7aae397
I'm also a Doom user, albeit a new one. What is making you consider the switch?
Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
I've had multiple config bankruptcies over the years until settling down with Doom. I'm considered "experienced Emacsian" - built and published packages, etc. I'm still using Doom but only the core of it. I don't even consume almost any of its "official" modules - I have my custom ones instead. I have considered building my own config from scratch (yet again), but I like Doom's core macros - map!, add-hook!, defadvice!, undefadvice!, etc. I'd probably inevitably end up borrowing them and structuring my new config just like I already have, so I see no point.
> I don't fully understand the editor
Going vanilla will not help you there - well, not completely anyway. Moreover, it may even obscure some features that were easily accesible before.
> I don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature
That is not very difficult - learn how to use built-in features - profiler, edebug, describe-, apropos-, hooks and advising, etc.; Start writing Elisp code (with understanding it). In the end, it won't really matter - whatever runs in your Emacs, there's always a way to get to the source. And if you ever need to disable any feature of Doom - there are multiple ways to do that.
Emacs is not great software because it has good features. It’s great software because it conforms itself and those features to the user’s needs and preferences. If one of those preferences is short, canned config, we’ve got a way to express that (spacemacs and doom). But if one can’t be arsed to express their preferences even in those frameworks … emacs might not be the software for them.
What are these things you have that makes Emacs a modern editor?
I have cua-mode and don't show startup message. What else do I need to modernize Emacs?
For your consideration, two Elisp packages I've written that focus on feature discoverability and use: Casual and Anju, both available from MELPA. You can read more about them at the following links: https://github.com/kickingvegas/casual https://github.com/kickingvegas/anju
treesitter (with easily installable grammars - a big pain point) / LSP integration OOTB / themability
Plus now agent integration (aka GPTEL)
These are all trivial to implement?
`treesitter` grammars _are_ easy to install.
`eglot` is available OOTB, `lsp-mode` is easy to install and configure if you prefer.
`gptel` is easy to install and configure.
I'm getting pretty good with Emacs, but I find its Treesitter handling a bit obtuse, and the auto-installation package I found slowed the editor down a lot for reasons I can't determine. (I mean, everything slowed down, and it all sped up again when I uninstalled the package.) I'm looking forward to revisiting this when Emacs 31 comes out, though.
I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.
Being many things, even if "easy to install" individually, can add up to a hassle to pick, research, install, and configure them.
Why even use `emacs` if you're not willing to learn the basics? There are plenty of alternatives that cater to that preference.
Vertico feels like a must-have to me these days. I also like to have treemacs installed.
Apart from that, I don't have a lot I insist on, and my used emacs package space keeps shrinking.
That said lately I use lem more than I do GNU emacs.
As a Vim user (just admitting to my ignorance here), is it not feasible to make something like this yourself? Emacs is said to be flexible and extensible enough, or at least I’m under the impression that it has that reputation.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).
I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)
This is how I justify not switching back to vanilla, despite not really being an evil user. Doom's module system is really great for organizing a config.
Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.
Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.
Richer in vscode, i'm not so sure.
Claude: configure my Emacs such that … has worked pretty well for me lately.
Ask Claude to reprogram the Emacs graphics display engine to provide 3D wireframe object relations to see Popper's World abstraction navigating World 3 to 1 and backup.
> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
IDEs exist to allow teams or entire divisions to hit the ground running with development, with a standard interface that everybody on the same team uses (a huge boon for collaboration), without a lot of time spent configuring or integrating the tools. All the integration is done by the vendor, often better than you can do it; the debugger integration in full-fat Visual Studio is still second to none.
Grooming a personal .emacs or .vimrc is fine if you're working alone, but when you're on a team of professionals working on an application built on a commercial platform, a standard workflow for development is essential and an IDE supplies all the tools, integrations, and conventions to cover the basics of such a standard. Do not underestimate their value.
TV dinners have their value, but a cooked meal is often better. And, just like meals can be cooked for a team, so can emacs configs.
I don’t mind IDE per se, Just like I don’t mind Game Consoles. It can be truly useful, as you say, to have something Plug-and-Play to hit the ground running.
But they often use subpar components (code editors, file managements, VCS,..). They are tailored to a specific standard and any deviation to that standard result in a lot of pain. So I much prefer documented tooling subset that can be integrated however you want than an IDE.
Also you usually spend more time using a system than learning it. Aiming thing to beginners increase longterm discomfort.
Bedrock Emacs is pretty much this, its what I finally used after I declared config-bankruptcy with Doom, and it gave me the room I needed to get my own setup together
https://codeberg.org/ashton314/emacs-bedrock
Reading Rahul's post I got excited to build Emacs 31 from source, but reality occurred and I decided to wait for the release. I also like his articles on setting up Emacs.
I don't care what tools other developers use but in January I made my two dev Macs 'VSCode free' and use Emacs for everything. Feels better!
For decades I would spend tons of time experimenting with my Emacs setups but in the last few years I have been shifting to more out of the box experiences. I did write my own agentic coding platform in Emacs Lisp but I keep that separate from .emacs and .emacs.d
I realize I've missed a lot.
Someone should write an Emacs guide for people who haven't meaningfully touched their .emacs since the early 2000s
The bulk of the Mastering Emacs blog is a decade old at this point, but its philosophy and the information it provides is still very relevant for any graybeard wanting to get up to date.
I'm a pretty conservative emacs user, partly because I don't want to spend time tinkering to get things to work consistently across Windows, ubuntu, and mac os -- all of which I use daily. My most "modern" adoption is probably using lsp and eglot with various language modes, notably golang and rust.
Should I consider adding tree-sitter into the mix?
Nah. It's great that they're making it less of a hassle to use, but it's still going to be more of a hassle than just using the plain regex-based modes, and treesitter in itself doesn't really make much of an improvement if you already have working syntax highlighting for some mode.
The main exception is if you want to program in a language that only has a treesitter-mode, or I suppose if the regular mode has quite buggy syntax highlighting / the ts-mode has much better features.
(There are also fancy minor mode packages like combobulate that make special use of treesitter, but that's tinkering territory.)
There's a lot of Emacs information on the internet, and your agent has been trained on it.
For real, ask your agent to do anything in Emacs and it simply knows how to do it.
It’s already built in! C-h n view-emacs-news
Wow, auto install treesitter grammars, editable xref, transposing window layouts, speed bar as a side window in frame, I had no idea any of these things were coming and were all some passing thoughts I’ve had in the last few weeks “it would be cool if this was supported OOTB”. Some dreams do come true!
> kill-region-dwim fixes a decades-old papercut. Set it to 'emacs-word and hitting C-w with no active region kills a word backwards instead of signalling an error.
Thank you! No more:
(defun cutregion-or-killword (beginning end) "Kills region if marked else backward kills word." (interactive "r") (if (use-region-p) (kill-region beginning end) (backward-kill-word 1)))
(global-set-key (kbd "C-w") 'cutregion-or-killword)
back in 2nd year of university I remember thinking that vim is complicated so i went with Emacs. Now after using vim for couple years , I can't imagine going to Emacs and learning it. The availability of vim emulation in majority of text editors and IDEs has been a lifesaver
although the brief time I used Magit I was enamored I gotta say. I tried lazygit recently and it evoked the same feeling I had when trying Magit for the first time
Emacs evil-mode gives you vim bindings.
Emacs is the best. Thanks a lot for writing this up!
It is definitely not the best. It is an acceptable but inferior product when compared to the gold standard. I have spoken!
Emacs can give you all the vim key bindings. Vim can't do that.
Excellent news! But what are the odds that “treesit-auto-install-grammar” is going to work on Windows? Finding precompiled grammars is so annoying. Windows support would be fantastic, and im hoping these improvements come to eglot next.
Excited to try out the native frame transposition this update and how it plays with pgtk
Thanks for sharing, frou_dh! Author here btw :)
Very cool! Looking forward to try out the xref and markdown features. The latter becomes increasingly important since the developer community at large seems to disagree with org-mode being the superior syntax...
I am getting SSL certificate errors trying to access this -- but it's in the Wayback Machine: <https://web.archive.org/web/20260618141735/https://www.rahul...>
Thanks, I've got some trouble with hosting and all the traffic.
Should be normalized now.
I recently sifted through a bunch of tagged entries in a text file, where each entry had a json array of image names, but the images resided on a remote server. I basically wanted a program that could detect if the cursor was on an image name, and display it on the right.
There's a bajillion ways to do this, some might even involve writing an html file and launching a remote server and tunneling and using a browser and what not. But no! ChatGPT wrote 20 lines of elisp code. I add a tramp basepath, open the text file, and got exactly what I needed. Need any behavior changes, callbacks, transformations? Modify, eval expression, new behavior!
I asked ChatGPT what other system I can use to achieve the same effect. The best answer it gave was neovim. No, neovim can't do that with the same degree of ease.
Disappointing and amazing at the same time.
The drawback of the emacs approach in my case is the tramp latency. To speed things up we'd want to add prefetch and that's gonna be much more than 20 lines and C-x e
Emacs works perfectly in sync with claude code/codex/opencode or any cli ai coding tools, it's never going to go away.
How do you use it in relation to claude?
Agent-shell.el for the CLI experience that's integrated with emacs. You can send things from emacs to your Claude code prompt and it will include the file and line numbers.
There's also claude-code-ide.el that gives you more of a cursor like experience with autocomplete, simple chat, etc.
claude-code-ide runs the claude TUI inside a term inside emacs with a little bit of editor integration on top. It's closer to the standard CLI experience than agent-shell is.
Not the person you're replying to, and I have no idea what they were referring to, but I use agent-shell.el and it is incredible:
https://github.com/xenodium/agent-shell
xenodium is doing some amazing work (and not just on agent-shell, either!)
Agent-shell.el and claude-code-ide.el
Agent-shell is like the Claude code CLI. Claude-code-ide is like cursor with ghost completions/auto complete, chat, etc.
Any tips. Or blogs/info you've found that you could share?
I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.
Emacs is more than a dev environment for coders. Some of us here use it for everything that can possibly be represented in text form: our TODO lists, our calendar, our RSS reader, our mail reader, etc. Me, I even maintain billing spreadsheets for a side business as Org-Mode tables. New features in the latest Emacs releases, and in successive releases of individual packages, have brought some nice improvements in those areas.
In 2026 I'm using the editor less and using magit a lot more. IOW, emacs has become more indispensable, not less.
Nice to know sr-speedbar can finally be retired. It works fine, but fewer external packages means simpler config.
>treesit-auto-install-grammar
Sweet. GLP1 for my .emacs!
I am always a little bit puzzled with the versions. I use Emacs from Snap on Ubuntu.
I have to use the pgtk channel, because Wayland.
pgtk/stable is 30.2, pgtk/edge is 32.0.50. Version 31 is not even offered on snap, in none of the channels. I am running on edge (32.0.50) with no problems.
"Is anyone still using emacs?"
I use emacs --daemon instead of tmux inside my agent sandbox for session permanence and portability. A full editor rather than a layer between me and my editor. I can even waypipe the client windows if I want mouse support.
I do the dinosaur version of this, with screen and xpra. Works great. CC and codex being terminal-native may make terminal-based (or at least terminal-comfortable) editors seem more natural to a broader set of people.
Why use screen? Just leave your emacs --daemon running, and when you reconnect, run emacsclient and all your buffers are back. And you only have to learn one method for arranging frames rather than both emacs' and screen's.
Exciting stuff, especially the tree-sitter changes.
Emacs is a fine weapon. And one that grows with you over the years of honing it to perfection. Nothing else compares.
"Is anyone still using emacs?"
I'd like to, but there is currently a RAM shortage
Emacs stands for "Eight Megabytes And Constantly Swapping". But in 2026 eight megabytes is pretty cheap.
By all means go back to the lean, memory-efficient VS Code, then
There is a superior, faster and more efficient alternative just at your fingertips waiting to unleash its magnificent power if you would only dare to dream big.
Oh, you mean that little modal editor I use to tweak config files?
[j_jonah_jameson_laughing.mp4]
Have they fixed MacOS startup performance yet? ISTR some post about why faster CPUs were making emacs even slower on startup. Seems to have gotten worse over the years.
You boot Emacs once as a server. Then you connect through that server through emacsclient. It is your OS after all.
Sure, that's one approach. But it shouldn't take 45 seconds to spin up a new "emacs -nw" process, IMO. There's something pathological going on.
emacs -nw takes about 2 seconds on my mac. I don't use server/daemon, and those 2 seconds are processing my startup elisp files (it's ready nearly instantly without prepping my junk).
It's so refreshing to see emacs just sticking to its guns and getting solidly, steadily better over the years. Inspirational, even. This is how software should be. Can't wait for all the tree-sitter improvements!
30.2 is as far as I am willing to go. Happy travels.
I’m curious as to why - is it a matter of stability/feature completeness in 30.2 that you don’t need or want to bother with new releases? Or that you don’t like the direction of the project past that point?
Same here. I'd probably still be using 24.4 if I didn't want PGTK support.
Thanks for your work.
Please, if you have something to do with Emacs, can you review this for NetBSD and OpenBSD when using gtk3:
https://www.unitedbsd.com/d/1621-emacs-30-wxaw
The issue was traced to library xinput2, when compiled with '--without-xinput2' the issue does not occur. But I do not know if that is something that Emacs can address.
> If you've ever built a three-window layout and then wished the editor pane were on the other side, these do the job and keep every buffer in place while they're at it.
I built a tmux like buffer manager. So I can just pick a window, press Alt-F#, and switch that pane over to whatever buffer I want. It's super easy to even display the same buffer twice but in different panes.
If you're using one without the other you're going to have a bad time.
If I want to change layouts I just close panes down to one and then open it up in the configuration I like. Then I just switch to each pane and Alt-F# the correct content into it.
It's nice to hear the emacs terminal emulator has gotten some love, after all the controversy about the nasty language that used to be in its source code, which rms moved out to a separate file after somebody complained.
Open source with profanity in comments is statistically better than code without it:
https://blog.desdelinux.net/en/open-source-with-profanity-in...
https://news.ycombinator.com/item?id=36621699
DonHopkins on July 6, 2023 | parent | context | favorite | on: Open source code with profanity in comments is sta...
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
https://opensource.apple.com/source/emacs/emacs-59.0.80/emac...
1990-08-26 Richard Stallman (rms@mole.ai.mit.edu)
* terminal.el: Move possibly offensive comments to term-nasty.el.
https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
[...]
[...] [...] [...] [...] [...] [...] [...] [...]https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".Jamie Zawinski kept Lucid Emacs nasty:
https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
Noah Friedman, Aug 3, 1992, 4:54:20 AM
In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess) writes:
>In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu (Noah Friedman) writes:
>>It's by no means necessary, but it's funny.
>Along the same lines, look at lisp/terminal.el
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
Thanks for this interesting bit of history! Fun little read
What’s the appeal of an editor like Emacs in 2026? Why’d anyone still use when most jobs nowadays require you to work inside a container (and therefore use VSCode container extension)?
I was using TRAMP to do that in Emacs 20 years ago. These days I use emacs-server in the container and waypipe my frames.
Can't you ssh into them? If so, in emacs you can just open /ssh:host:path/to/file and remotely edit that file.
Even if you didn't have emacs, I don't think you are forced to use VSCode. You could just use sshfs and use any local editor, but I guess other editors also have remote editing plugins