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.
> 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.)
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!
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'.
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.
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 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 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.
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.
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!
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)
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.
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.
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.
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?
> 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.
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.
>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?
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.
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...
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.
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.
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
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.
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!
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.
>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).
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.
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.
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.
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.
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.
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.
> 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?
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.
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!
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.
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
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 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 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.
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.
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.
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
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
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!
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.
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
"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
> 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.)
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!
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
Wow, so you used the earliest public versions. Ever written a retrospective of what 40 years of Emacs has been like?
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!
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.
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.
Likely because they haven't seen the light just yet. Or they are lost to the evil forces.
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.
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.
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!
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)
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.
> 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?
> "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.
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.
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?
> 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)
"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!
And Ghostel support recently landed in claude-code-ide.el!
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.
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.
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.
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...
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.
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.
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.
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
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.
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.
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
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.
Sigh. Don’t be “that guy.”
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?
Both Doom and Spacemacs work fine without the vi bindings.
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.
And then slowly over 20 or so years deleting all of it.
I think I'm down to about 110 lines of ~/.vimrc now :}
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.
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.
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.
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.
Claude: configure my Emacs such that … has worked pretty well for me lately.
> 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
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?
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
> 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.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!
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.
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 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?
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!
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...
Excited to try out the native frame transposition this update and how it plays with pgtk
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 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.
Thanks for sharing, frou_dh! Author here btw :)
"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.
Nice to know sr-speedbar can finally be retired. It works fine, but fewer external packages means simpler config.
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.
>treesit-auto-install-grammar
Sweet. GLP1 for my .emacs!
"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.
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
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.
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
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.
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.
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