Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity.
Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, or packages were inadequately maintained. So now, I tend to use it for quick, short code writes, especially when I'm remoted in to a server. I also use it for org-mode, and for writing my book.
Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs.
I use VSCode for quick scripts, and for when I need to do maintenance work on some old php code. I like it fine. It fits in this really nice place between a full IDE and a bare bones text editor like Notepad or even BBEdit (ha!).
I was fully down the path you're talking about, and would have agreed with you... until COVID happened and I've been stuck working from home on a fairly low bandwidth (rural) Internet connection with source code that can't (because of BigCorp policy) be on my local machine. So it's SSH for most things, and suddenly my 25+ year old emacs skills (such as they are) have come back to be a big help.
That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems.
So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.
Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it.
Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something performant for a very large python codebase, and I did some more fiddling to adjust some delays and whatnot to get everything feeling snappy with the way I edit text. I still find that it feels faster on Linux than on Mac, but I don’t use the latter much anymore anyway.
My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
I use lsp for python and c++. It's usually good, but lsp will sometimes have the clang seever crash repeatedly, which can usually only be fixed by restarting emacs.
I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself)
All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
I use Emacs professionally for Ruby development and LSP (Solargraph) is a huge part of what makes it work smoothly.
I also do a lot of hobby Flutter/Dart development and the same is true there.
Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
I use LSP for Rust (rust-analyzer) and C++ (ccls) and I would say the experience is pretty good. For C++ projects I generate a compile_commands.json (Ninja, CMake or meson should help) and after that it's smooth sailing. I get contextual auto complete suggestions (yasnippet and complete even fills function arg placeholders), definition lookups, find all references, alternate between header and source, etc.
JetBrains has a straightforward way to pay for all that development and polishing time, which is lacking (due to sound but foundational reasons) on the emacs side.
I hear what you're saying, as I regularly run up against the rough edges of emacs too, but buffers and org-mode are absolute gamechangers for me and my productivity.
I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity.
That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1].
I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching
I'm in the same position. I've used Emacs intensively for 20 years and I'm the author of Emacs packages that other people use. Nowadays I work on Python, Rust, and Typescript/$JSFramework projects. Here are some of the requirememts:
- Completions need to take the type system into account (even in Python), etc.
- Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc
- It has to be easy to set the interpreter path for every one of the executables involved.
- This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume.
Clearly nowadays this has to be done with LSP.
I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering.
So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.
> it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which)
It, uh, depends on the 1st and the 3rd of the mentioned packages.
> it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering
Joao has been saying that for a while, but seems like he has noticed after all that only a tiny percentage of the users get around to reporting bugs to Debbugs. Hopefully, that idea is dead now, or at least very much dormant.
On the other end, lsp-mode has been making strides in becoming more stable and polished, and making bells-and-whistles easy to turn off. So maybe try it again too.
To the four bullet points you mention, I'll add a meta-point: this all needs to be easy to set up simultaneously, per language. That's where commercial IDEs and editors shine - you get all these things properly set up out of the box.
In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
Don't you miss having the same keyboard shortcuts across programs?
Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line?
Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.
A sizable portion of the Jetbrains IDE functionality can be accessed by the keyboard. Moreover, the keybindings can be configured very similar to Emacs quite easily (I don't want to live without C-x C-2 etc. for splits for instance). There's a couple of helpful plugins, too. And for hardcore, straightforward editing I've bound Cmd-e to launch emacsclient right at cursor position. This goes quite a long way, IMHO.
Personally, I miss Notepad++'s tab and shift-tab behavior with multiple selected lines on nearly everything, but except for that, I don't usually miss a tool behavior on another tool.
It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL.
1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
A lot of IDEs have options to enable emacs-like key bindings. But the mapping is imperfect, and sometimes it gets frustrating. But I tend to work in one environment at a time, so after the initial frustration, I'm fine.
I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
I'm a Vim user, not Emacs and don't know anything about the ecosystem, but I just wanted to say I've never ever convinced myself that the hundreds of hours I've put into hacking on my Vim setup is "productivity". It's all recreational. I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. I imagine it's the same for many Emacs users.
> I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it.
This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...
A heads-up that VSCode's remote extensions and Python LSP (pylance) are proprietary. So they can't be used in forks like VSCodium. Pylance is set to replace the current Python LSP.
So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary.
Possibly more core extensions could become proprietary.
PS: I know MS created LSP, so no need to remind in reply.
Same experience here, but as a Vim and IntelliJ user. I can edit a single file or a few buffers in Vim maybe twice as fast as I can in IntelliJ. However, I can navigate through a codebase 5x as fast, which means that when I’m doing anything that requires an understanding of parts of the codebase I haven’t memorized (95% of it), my IDE is speeding up my development by nearly 5x.
I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.
But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time.
It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need.
> Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs.
It can be said for any other text editor. Of course, specialized tools are better most of the time.
The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features.
LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
>LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
As usual it boils down to the right tool for the job.
Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.
Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
I thought about it a lot, and realized there's one big obstacle for Emacs to be as close to a silver bullet as you can get - reconciling the following needs:
- Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI.
- Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other.
- Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web.
The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot).
Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM.
(And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)
Haha... Good joke. But jokes apart, I've been using it to write book, refcards, blogs and programs I've never faced this 'feature'. In a proficient hand a good tool shines; Emacs ia no exception.
I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular was the availability of many high-quality extensions for major languages. Unfortunately, my experience with Elisp packages is that they tend to be much less stable. This is changing some with LSP mode, of course, but I think the Emacs community would do well to focus on improving the story for plug-in stability in the long-term. I already have to install use-package to make handling packages reasonable, which is not something I have to do in other editors. Manually setting up hooks for them is a pain in the ass too.
I once submitted a bug to the Emacs mailing list and after determining it was indeed a defect, a flame war ensued between maintainers of different subsystems that were competing over how a specific feature was supposed to be used, which was the source of the bug. It was offputting and felt juvenile. Social problems are inevitable in any open source project, but I can’t help but wonder if the highly dynamic nature of Emacs Lisp causes more problems than a less dynamic language would.
I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.
VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.
By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
I'd love to be wrong about that, though, and one day get the best of both worlds.
> I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.
I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.
> the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
This is actually how I feel about VS Code! I'm a VIM user (both in and out of VS Code), and there are things I regularly go to MacVim for that the VS Code plugin doesn't support.
The thing that keeps me coming back to VS Code isn't the quality of the editor or the quality of any one thing. It's the quantity of "good enough" plugins and its integration of a good enough terminal.
>I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
There's no excuse for Emacs to be as inaccessible as it is though. What is "crucial difficulty?" You write an awful lot of words to excuse why the world's most powerful text editor does not have a high level of polish or usability out of the box. Usability is not at odds with power: it's complementary. The rich extension ecosystem is amazing, and there are tools in it that cannot be had anywhere else (Magit is my git client for everything, even when using IntelliJ and VSCode). But the number of extensions that exist to fix bad and/or obsolete defaults, and the number of extensions that add basic usability improvements, is really high as well.
I'm not advocating for eliminating what makes Emacs Emacs. I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power. In short: I don't believe its messiness is an inevitable effect of its power. I think it's a product of the attitude that certain things about it should suck to weed out users who don't fully agree with its ideology.
>By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
I say this as an OCaml and Elixir programmer: there's nothing wrong with writing Java. The world runs on Java, not Lisp. Statistically speaking more Emacs users probably use it to write Java than any other programming language. If we're not going to meet the world where it's at, we will fail eventually.
That is only true for the low level tasks out of the box. Adding a simple command is very easy. But doing something more complex can be very painful in emacs.
VS Code on the other side is out of the box focusing on flawless experience and supports hacking only through hidden paths. Though, install a simple extension and it's as simple as emacs. While having still a better experience on more complex tasks.
> VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily)
This again is just the out of the box-experience. Modal editing is possible, though it's true that there is still place for improvments. Which is ok for an editor which is just 5+ years old. The project seems to play a strategy there it unfolds from a safe corridor of stability and adding more and more abilitys, instead of starting from open chaos and trying to control it.
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code
Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors.
Only a small portion of the article is about SW development.
The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.
I use Emacs primarily for things other than editing and navigating code:
I maintain many files of notes;
I rename files and view directory listings (using Dired);
I pass command lines to Bash to be run. (End of list.)
More to the point, whereas vscode would prove a mostly satisfactory replacement for Emacs for editing and navigating code, it is unlikely I will find a mostly satisfactory replacement for Emacs for the tasks listed above. (And I have been looking: I evaluated for example the most likely of the recent spate of vscode extensions for maintaining notes in markdown files.)
(I don't like keyboard-only UIs; like 68.1% of the Emacs users who responded to a recent survey [1] I never use a terminal or terminal emulator to interact with my Emacs.)
I guess I should explain why a terminal app such a Gnome Terminal would not be a mostly satisfactory replacement for Emacs for submitting command lines to Bash. Like at least one other participant [2] in this comment section, I appreciate being able to use the same set of operations on the output of the Bash process as I use on any other file being edited (without my first needing to copy the output from my terminal app, then paste it into my editor). I also appreciate the fact that the Emacs Lisp code that runs when I send a line of code to Bash is vastly easier to modify than Gnome Terminal would be.
>Only a small portion of the article is about SW development.
The article, is, however written by a software developer.
>The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Do we have any hard data here? Or is this just an anecdote?
Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code
I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.
I first used emacs 25ish years before VSCode existed and VSCode was pretty much immediately easier to use and customize; to be fair, it's not like I was using Emacs heavily in the intervening quarter century, but I was using it fairly regularly.
OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
From what I can tell, the relative instability of Emacs comes from two things: the lack of well-supported concurrency primitives and defadvice. The former is the source of UI lockups, and if you're really out of luck, you'd have no other choice but to kill the Emacs process. The latter is a footgun in Elisp that allows you to replace or hook into any function defined in Emacs.
I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.
I have to disagree -- in part -- about the advice system: used sparingly, I think it's one of the killer features that lets me tweak emacs exactly how I want it.
That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.
Yeah, I wouldn't touch defadvice itself. We can talk about reminding elisp developers to use it only as a last resort, but ultimately, it is a very important feature, that lets you make modules cooperate even if they don't want to.
> I once submitted a bug to the Emacs mailing list and after determining
> it was indeed a defect, a flame war ensued between maintainers of
> different subsystems that were competing over how a specific feature
> was supposed to be used, which was the source of the bug. It was
> offputting and felt juvenile. Social problems are inevitable in any
> open source project, but I can’t help but wonder if the highly dynamic
> nature of Emacs Lisp causes more problems than a less dynamic language
> would.
Commercial developers have many internal discussions, with the
difference that they will not show it to you.
Emacs has a lot of amazing extensions! Magit is unparalleled for working with Git. The problem is that they break more frequently, in my experience. The very fact that I have to install a 3rd-party DSL to have a sane package management experience is beyond the pale from a usability perspective.
This happened all the time at a couple of companies I worked for. The advantage there however was the customer who filed the bug report couldn’t see all the emails bouncing around between teams over who was to blame and who needed to fix the problem.
As an Emacs and Lisp lover, the description of text-based tools and the power of using text to me just screams why something like Lisp is so powerful: homoiconicity. (And at least one big difference for elisp compared to Bash.) To quote Wikipedia [0] for anyone unfamiliar with the term, as I was until learning some Lisp:
"A language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself. This property is often summarized by saying that the language treats "code as data"."
I've been hearing the "code is data" mantra often, but the reason I never thought this was a desirable property is that it seems trivial to define any number of languages as their own AST. But there is a good reason that we don't program by writing out ASTs - it's relatively hard to read and manipulate. Does the Lisp implementation just happen to be particularly readable?
Although (as a keen Emacs user & someone who often hacks into existing librairies) user I'm not really convinced either that homoiconicity plays that huge of a role in Emacs malleability in particular -- to me it's more about hooks/advice system and being able to dynamically override things to tweak into the way I want them to behave -- and I don't see a good reason why this couldn't be possible in other languages.
LISP syntax is a data format. Unlike JSON though, its only structured data type is linked lists. `(a . b)` represents a linked list node (a pair or a `cons`) with the symbol `a` as first element and `b` as the second. The syntax `(a b c)` is a shorthand for `(a . (b . (c . nil)))`, with `nil` representing the empty list. It is commonplace to define what we nowadays call embedded DSLs using macros, which are just functions that manipulate LISP data structures before the interpreter evaluates them.
It is the first dynamic programming language, and arguably the most dynamic one. The only other non-esoteric language that comes close is PL/I, which also had macros and where every keyword could be redefined. But its standard is ungodly long, while Scheme dialects can be descriped in a few tens of pages. Also, it is quite easy to write an interpreter for core LISP: 100 to 200 lines, depending on your desire for readability.
Edit: Yes, this means there are lots of parentheses, which can be hard to read.
The ast of a lisp program is essentially the same as the code of lisp itself. There is no intermediary step. Practically I'm sure there is, but conceptually that is they way it behaves.
In a word, yes. S-expressions are a decent representation for data (lists and hierarchical structures) and the sort of code you write in a language derived from the lambda calculus, which is function calls. This is not by accident, though, since it is very desirable to manipulate code via macros.
It's kinda of a messy concept. Source code is never like an AST, because an AST is a tree on a computer's memory, with pointers and everything, while source code is text.
I see no reason why a language can not have a more complex source -> AST transformation, while still keeping code as readable data that can be manipulated by macros. So, if you want homoiconicity with a slightly more complex syntax, I don't think it won't bring any problem.
But if you keep making your language's syntax more and more complex, you will make macro creation harder and harder, so there is probably a practical limitation somewhere. Operators and statement sequences are very likely not complex enough to be a problem, but I don't think anybody will ever make native C++ macros work.
In addition to the other replies, I think it always takes time to learn a new language and its syntax, preferred formatting, etc. So I don't know what is more "natural," as that would depend on your background, but once I learned s-expressions it is my favorite way to read code. (Combine that with Emacs to handle all formatting, parens matching, and so on, and you can just think about code rather than decipher it too.)
This is pretty tangential, but I don't understand why there isn't a roguelike framework available for Emacs. It seems like the perfect roguelike platform for playtesting and hacking on and would on-board a lot of new people into the Emacsen ecology without any real difficulty. The standard roguelike library libtocd has bindings for every other language--why not elisp?
It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.
It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).
To be clear, it's not a general-purpose roguelike engine, but it proves that with enough effort such an iterative developer experience of modding a game can be achieved.
I've wondered the same thing! In particular, the highly polished and powerful interfaces of some roguelikes (DCSS comes to mind) strongly remind me of Emacs. It seems like the scriptability and power of Emacs interfaces is a natural fit for roguelikes.
That's funny. I've wondered that too, and from the other replies it seems you and I aren't the only ones. I half-assumed it existed and was just called something-incomprehensible-mode so I never heard of it.
I used to play Nethack within Emacs using nethack-el. It was really useful being able to bind a shortcut to something that could copy the map and append it to a text file with a note. :)
Emacs is a text UI (though it can show images too) on top of a cross OS programming platform where you can create quick UIs for any kind of task you have (interfacing with APIs, command line programs, editing tasks, etc.).
Once you learn how Emacs works and how it can be programmed, you can create interactive tools extremely quickly to make lots of tasks you encounter day to day easier. I do this all the time.
"Writing GNU Emacs Extensions" by Bob Glickstein is a solid introduction. After that, the Emacs Lisp reference manual (available as "info elisp" in the shell) gives much more detail.
Inside Emacs, you can:
- "M-x apropos" to search for commands of interest
- "C-h f" to get documentation for particular functions by name
- "M-x find-function" to jump to the definition of a particular function
- "M-x find-library" to load a library into a buffer so you can read and (depending on your permissions) edit it.
The Elisp reference is very good, and most libraries are well documented. Between that, the ability to jump around the code base, and trying things out in the "scratch" buffer (it's an Elisp REPL disguised as an editing buffer), you should be able to get quite far.
The author is definitely right in saying that Emacs is an OS, because it runs "programs" that interact with a common datasource. The issue is that those "programs" are not the ones of your baremetal host.
The sequel that makes sense would be a text editor that allows host programs to be run seamlessly on the text. Once again the geniuses behind Plan 9 have shown how novel their system was by creating acme (https://www.youtube.com/watch?v=dP1xVpMPn8M). It allows any program to interact with whatever is in the text, so it clearly is the 2D cli the author is looking for
Its also a daemon that does a lot of work for me from the shell!
I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, create pdf reports and write-ups, prompt me to check-in any leftovers at the end of the day, work seamlessly across my machines, provide menus to give access to files, clickable functions, org-summaries, fantastic spreadsheets .. oh wait, that's going beyond shell.
so yes, it made my beard grey. big deal, i can shave. sure it not perfect, sure its infuriating, surely i'm insane for continually investing into my future while tweaking something to compound its benefits.
but none of this makes emacs anything but a lisp machine -- so well loved and so close to the metal that it will be here after you and me. Call it a general purpose computing shell, not an OS, and please compare it to the living, not the dead!
Can you do all of those without emacs ? My point is that yes Emacs can do so many things, but 1) it's all accessible from Emacs only and 2) it uses Emacs-only components. This is fine if you live inside Emacs, but it doesn't really integrate with the rest of your system
Just like Emacs is a poor imitation of the developer experience on Lisp Machines, ACME is a poor imitation of developer experience on Oberon and Mesa/Cedar.
Readit News
Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, or packages were inadequately maintained. So now, I tend to use it for quick, short code writes, especially when I'm remoted in to a server. I also use it for org-mode, and for writing my book.
Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs.
I use VSCode for quick scripts, and for when I need to do maintenance work on some old php code. I like it fine. It fits in this really nice place between a full IDE and a bare bones text editor like Notepad or even BBEdit (ha!).
That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems.
So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.
Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself)
All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
I also do a lot of hobby Flutter/Dart development and the same is true there.
Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity.
That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1].
I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching
[1] https://github.com/microsoft/pylance-release/issues/4
- Completions need to take the type system into account (even in Python), etc.
- Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc
- It has to be easy to set the interpreter path for every one of the executables involved.
- This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume.
Clearly nowadays this has to be done with LSP.
I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering.
So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.
It, uh, depends on the 1st and the 3rd of the mentioned packages.
> it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering
Joao has been saying that for a while, but seems like he has noticed after all that only a tiny percentage of the users get around to reporting bugs to Debbugs. Hopefully, that idea is dead now, or at least very much dormant.
On the other end, lsp-mode has been making strides in becoming more stable and polished, and making bells-and-whistles easy to turn off. So maybe try it again too.
In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
Deleted Comment
Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line?
Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.
It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL.
1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...
So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary.
Possibly more core extensions could become proprietary.
PS: I know MS created LSP, so no need to remind in reply.
Why do you keep creating throwaway accounts for this?
Write a full blog post about it and get it on HN. People will for sure upvote it to the front page.
I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.
But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time.
It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need.
--
See https://xkcd.com/974/, https://xkcd.com/1205/ and https://xkcd.com/1319/ for the common arguments.
It can be said for any other text editor. Of course, specialized tools are better most of the time.
The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features.
LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed.
Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
- Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI.
- Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other.
- Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web.
The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot).
Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM.
(And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)
Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.
I once submitted a bug to the Emacs mailing list and after determining it was indeed a defect, a flame war ensued between maintainers of different subsystems that were competing over how a specific feature was supposed to be used, which was the source of the bug. It was offputting and felt juvenile. Social problems are inevitable in any open source project, but I can’t help but wonder if the highly dynamic nature of Emacs Lisp causes more problems than a less dynamic language would.
VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.
By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.
I'd love to be wrong about that, though, and one day get the best of both worlds.
I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.
This is actually how I feel about VS Code! I'm a VIM user (both in and out of VS Code), and there are things I regularly go to MacVim for that the VS Code plugin doesn't support.
The thing that keeps me coming back to VS Code isn't the quality of the editor or the quality of any one thing. It's the quantity of "good enough" plugins and its integration of a good enough terminal.
There's no excuse for Emacs to be as inaccessible as it is though. What is "crucial difficulty?" You write an awful lot of words to excuse why the world's most powerful text editor does not have a high level of polish or usability out of the box. Usability is not at odds with power: it's complementary. The rich extension ecosystem is amazing, and there are tools in it that cannot be had anywhere else (Magit is my git client for everything, even when using IntelliJ and VSCode). But the number of extensions that exist to fix bad and/or obsolete defaults, and the number of extensions that add basic usability improvements, is really high as well.
I'm not advocating for eliminating what makes Emacs Emacs. I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power. In short: I don't believe its messiness is an inevitable effect of its power. I think it's a product of the attitude that certain things about it should suck to weed out users who don't fully agree with its ideology.
>By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.
I say this as an OCaml and Elixir programmer: there's nothing wrong with writing Java. The world runs on Java, not Lisp. Statistically speaking more Emacs users probably use it to write Java than any other programming language. If we're not going to meet the world where it's at, we will fail eventually.
That is only true for the low level tasks out of the box. Adding a simple command is very easy. But doing something more complex can be very painful in emacs.
VS Code on the other side is out of the box focusing on flawless experience and supports hacking only through hidden paths. Though, install a simple extension and it's as simple as emacs. While having still a better experience on more complex tasks.
> VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily)
This again is just the out of the box-experience. Modal editing is possible, though it's true that there is still place for improvments. Which is ok for an editor which is just 5+ years old. The project seems to play a strategy there it unfolds from a safe corridor of stability and adding more and more abilitys, instead of starting from open chaos and trying to control it.
Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors.
Only a small portion of the article is about SW development.
The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.
I maintain many files of notes;
I rename files and view directory listings (using Dired);
I pass command lines to Bash to be run. (End of list.)
More to the point, whereas vscode would prove a mostly satisfactory replacement for Emacs for editing and navigating code, it is unlikely I will find a mostly satisfactory replacement for Emacs for the tasks listed above. (And I have been looking: I evaluated for example the most likely of the recent spate of vscode extensions for maintaining notes in markdown files.)
(I don't like keyboard-only UIs; like 68.1% of the Emacs users who responded to a recent survey [1] I never use a terminal or terminal emulator to interact with my Emacs.)
I guess I should explain why a terminal app such a Gnome Terminal would not be a mostly satisfactory replacement for Emacs for submitting command lines to Bash. Like at least one other participant [2] in this comment section, I appreciate being able to use the same set of operations on the output of the Bash process as I use on any other file being edited (without my first needing to copy the output from my terminal app, then paste it into my editor). I also appreciate the fact that the Emacs Lisp code that runs when I send a line of code to Bash is vastly easier to modify than Gnome Terminal would be.
[1] https://emacssurvey.org/2020/
[2] "I really like being able to move about the terminal field as if it were a text file" in https://news.ycombinator.com/user?id=jonnycomputer
The article, is, however written by a software developer.
>The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.
Do we have any hard data here? Or is this just an anecdote?
Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.
OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
Deleted Comment
2. Did your journey into computing start with CLIs, TUIs, GUIs?
I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.
That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.
Commercial developers have many internal discussions, with the difference that they will not show it to you.
Sample size = 1.
"A language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself. This property is often summarized by saying that the language treats "code as data"."
[0] https://en.wikipedia.org/wiki/Homoiconicity
(Edit: and if you want a good terminal emulator, you have eshell (emacs-y), ansi-term, and my current fave vterm [1])
[1] https://github.com/akermu/emacs-libvterm
Another benefit apart from macros is that you can replace whole subexpressions to modify the function code: https://github.com/raxod502/el-patch#el-patch Although arguably you can achieve the same with source code and other languages: https://github.com/adamchainz/patchy#patchy
Although (as a keen Emacs user & someone who often hacks into existing librairies) user I'm not really convinced either that homoiconicity plays that huge of a role in Emacs malleability in particular -- to me it's more about hooks/advice system and being able to dynamically override things to tweak into the way I want them to behave -- and I don't see a good reason why this couldn't be possible in other languages.
It is the first dynamic programming language, and arguably the most dynamic one. The only other non-esoteric language that comes close is PL/I, which also had macros and where every keyword could be redefined. But its standard is ungodly long, while Scheme dialects can be descriped in a few tens of pages. Also, it is quite easy to write an interpreter for core LISP: 100 to 200 lines, depending on your desire for readability.
Edit: Yes, this means there are lots of parentheses, which can be hard to read.
I see no reason why a language can not have a more complex source -> AST transformation, while still keeping code as readable data that can be manipulated by macros. So, if you want homoiconicity with a slightly more complex syntax, I don't think it won't bring any problem.
But if you keep making your language's syntax more and more complex, you will make macro creation harder and harder, so there is probably a practical limitation somewhere. Operators and statement sequences are very likely not complex enough to be a problem, but I don't think anybody will ever make native C++ macros work.
[0] https://github.com/dungeon-mode/game
[1] https://old.reddit.com/r/emacs/comments/jar7tz/dungeonmode_f...
[2] https://directory.fsf.org/wiki/Dungeon-mode
https://github.com/Ruin0x11/OpenNefia
It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.
It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).
To be clear, it's not a general-purpose roguelike engine, but it proves that with enough effort such an iterative developer experience of modding a game can be achieved.
That's false, as it does have the great Evil editor.
Once you learn how Emacs works and how it can be programmed, you can create interactive tools extremely quickly to make lots of tasks you encounter day to day easier. I do this all the time.
Inside Emacs, you can:
- "M-x apropos" to search for commands of interest
- "C-h f" to get documentation for particular functions by name
- "M-x find-function" to jump to the definition of a particular function
- "M-x find-library" to load a library into a buffer so you can read and (depending on your permissions) edit it.
The Elisp reference is very good, and most libraries are well documented. Between that, the ability to jump around the code base, and trying things out in the "scratch" buffer (it's an Elisp REPL disguised as an editing buffer), you should be able to get quite far.
https://www.gnu.org/software/emacs/manual/html_node/eintr/in...
This manual is also the part of the emacs distribution.
The sequel that makes sense would be a text editor that allows host programs to be run seamlessly on the text. Once again the geniuses behind Plan 9 have shown how novel their system was by creating acme (https://www.youtube.com/watch?v=dP1xVpMPn8M). It allows any program to interact with whatever is in the text, so it clearly is the 2D cli the author is looking for
I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, create pdf reports and write-ups, prompt me to check-in any leftovers at the end of the day, work seamlessly across my machines, provide menus to give access to files, clickable functions, org-summaries, fantastic spreadsheets .. oh wait, that's going beyond shell.
so yes, it made my beard grey. big deal, i can shave. sure it not perfect, sure its infuriating, surely i'm insane for continually investing into my future while tweaking something to compound its benefits.
but none of this makes emacs anything but a lisp machine -- so well loved and so close to the metal that it will be here after you and me. Call it a general purpose computing shell, not an OS, and please compare it to the living, not the dead!
Just like Emacs is a poor imitation of the developer experience on Lisp Machines, ACME is a poor imitation of developer experience on Oberon and Mesa/Cedar.