Emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. — Neal Stephenson
Quite so, and that essay is what made me try to learn Emacs.
I failed.
The UI is terrible and now, over 30 years since CUA imposed a necessary and very welcome degree of harmony and standardisation on text-mode UIs, I am not learning a another awful 1970s-style UI, no matter how much power it offers me.
Use the same UI and the same terminology for it as every graphical app in the world since before many current FOSS programmers were born, or GTFO. Alt-F opens the File menu, alt-E opens the Edit menu. Ctrl-X is cut, Ctrl-V is paste, Ctrl-C is Copy. Ctrl-P is print, not that that matters much any more. Ctrl+left & right cursor keys moves a word at a time.
I don’t have a Meta key. Neither do you, and neither do any of the Emacs developers. The last new production keyboard with a Meta key was made about 40 years ago or something.
Any keyboard younger than human middle-age has Alt, Ctrl, Shift and maybe Super/Windows/Command keys and nothing else.
A “window” is a region of the screen belonging to one program with a title bar at the top.
Times change. Language changes. Successful computers adapt to this. If it doesn’t, if it maintains its own terminology from 50 years ago, then fine, programmers from 50 years ago can keep it.
Secondly, I am not a programmer; I write English, not any programming language. There is so much bloat aimed at programmers in Emacs that it totally hinders learning and using it, and I can’t find any way to turn it all off. For example, I don’t want syntax highlighting, unless it understands the syntax of English.
I am 100% perfectly delightedly happy for all this stuff to remain there as an option for those who know it. All the hideous old cruft can be enabled if so much as an ~/.emacs file is present, or something.
But if its fans want it to survive and thrive, it needs new users and new maintainers, and that means meeting 21st century computer users in the middle. Adapt to the terminology that has become standard since, you know, MS-DOS in 1981 and the Macintosh in 1984. Adapt to the keys present on every keyboard.
I am typing on a 32 year old keyboard right this second, and it does not have a Meta key. It has Alt and Ctrl and it doesn’t even have Windows keys because it predates Windows 95.
This stuff is old now. Adapting to it is not heresy. It’s not some horrid recent thing. These are the established standards that I learned when I started in this industry in 1988 for hypothetical deities’ sake.
It is strangely appropriate to remix a Unix meme into an Emacs one. Well played.
But of course the thing is that Unix has grown up and become a lot more friendly. A modern Linux distro is pretty much up there with Windows and close to macOS.
The result, or one of the results, is that there are orders of magnitudes more xNix users now than there’ve ever been before. ChromeBooks sell in the hundreds of thousands a year, and Macs aren’t far behind, and they’re all Unix machines. UNIX™ in the case of macOS.
Wouldn’t it be good for Emacs if the same happened to it?
Oddly enough, I realise that. But the point that is clearly spelled out in the Neal Stephenson essay we’re commenting about here is that many feel that it is also the ultimate text editor. That’s the quote, right there, 3 comments up. If you haven’t, you really should read the essay. It’s one of the most insightful pieces of mainstream (non-technical) writing about operating systems ever, IMHO.
That is my point. If it’s so customisable, then it should be easy to just make some modest tweaks so that it conforms to the terms and the keystrokes that are now standard from Notepad to VS Code to macOS Text Editor to Kate… and if they are only the default for new users who don’t have an existing config file, this won’t hurt or even inconvenience the experts.
Secondly, while I’m a journalist again these days, I spent most of the last decade being a technical writer. You may not know this, but not only programmers use programmers’ editors. A lot of other non-development staff in multiple companies use code editors to write in; it is an entire philosophy of technical writing, called Docs as Code, used from Red Hat to SUSE to Cloudflare.
Tools such as Markdown, AsciiDoc, and Restructured Text, all flow from the docs-as-code camp.
It is easy to rebind the keys? Maybe you should use a less configurable editor.
Not everything has to be everything to all men. In particular by having the ability to be anything, emacs requires you to have the ability to use that configurability. In a similar way, I’m terrible at making things with basically any art supplies. And yet, people continue to use and pay for these things.
If you can’t find an editor that works for you, ask a colleague or friend what they use. Using any editor is a skill, and as such needs to be learned, and is learned best when taught.
Emacs shines for me because I can use it for any editing, and don’t ever need to learn a new editor (instead my effort goes into customizing particular modes). As far as I can tell, vim users value the same thing. If you don’t actually need to edit lots of types of code, then maybe emacs isn’t for you.
VSCode in particular seems to be an attempt to occupy a slightly different point on the configurability/genericity spectrum that is a bit more rigid overall but also requires creating a language server to add a new language (even more difficult). It’s OK for that to be better for your needs - it’s certainly a good editor for people to invest their time in learning that will probably work well as a life long editor for lots of people.
I am not saying it needs to be easier to use. That ship has sailed. There are probably 1000 editors that are easier to use.
I’m not saying it needs to be a word processor. That is not its purpose.
I am saying it should use the same standard UI that basically all other text editors settled on ~30 years ago, except for a handful of weird outliers in the Unix terminal (Vi, Joe, Pico, etc.)
That if it did, it would be easier for newcomers to pick it up, and that would win it more users, and help ensure its ongoing health, vitality, maintenance, and ongoing development.
There really isn’t a downside to this. Those who know how to use it already do and would not be inconvenienced.
Yes there is. CUA bindings overlap with the standard Emacs bindings in many ways. They are strictly worse than the Emacs bindings. If anything, more non-Emacs programs should abandon the CUA style.
There may be a decent argument for switching to vi bindings, but I don’t think that there is a great one for switching to the CUA ones.
That is so laughably absurd I am amazed anyone could say it and really mean it.
The war is over. It was over last century. There is a standard set of keystrokes, of terminology. Keyboards don’t have Meta keys. I am 55, I have been using computers for some 45 years, and I do not believe I have ever seen a single computer with a Meta key. Since the mid-1980s, it’s been Ctrl (“control”) and Alt, maybe Apple or Command or ⌘, or Windows. I’ll allow “Super” for this since there is no single alternative.
This is so long forgotten now that authoritative sources get it wrong, e.g. this:
«
On Windows the META key is the Window (⊞) key.
On Mac machines the META key is the Cmd (⌘) key.
»
That is flat wrong. Alt = Meta. Windows/Cmd = Super.
This is a real, serious issue, and just dodging it on the basis of “we’ve always done it this way” is beyond wrong-headed into risible.
Das ist nicht nur nicht richtig; es ist nicht einmal falsch!
On a GUI, which is most of them, programs open in windows. The window may be full screen, but it’s still a window.
There are standard keystrokes for word left, word right, select forward, select backwards, select upwards, etc. etc. Ditto for file open, file save, print, cut, copy, paste.
It’s a written formal documented standard from forty years ago.
It is obeyed by Windows, OS/2, DOS since 4 or so, classic MacOS, Mac OS X, every graphical desktop on every Unix in the world, every mainstream GUI text editor on every computer with a keyboard.
The Emacs adherents remind me of Shoichi Yokoi. He was the Japanese sergeant who remained in hiding on Guam for 28 years, until 1972.
It’s all over, folks. The side that won aren’t the baddies any more. They never were. They just wanted everyone to be able to talk to each other using the same words and the same commands.
I am really sorry that you are still hiding and pretending that you’re still fighting in the war, but it’s over. Peace broke out in 1987, when Richard Stallman was 25 years old. Within about three years, the last holdouts gave up.
Vim and Emacs may still be sweating in caves on mountains somewhere but the war is finished.
Started with Vim, went to Emacs, installed evil-mode to get the best of both worlds, and have been using that for the last few years now. Emacs is really a treat.
Right, when people say Emacs is a good operating system, but needs a good editor, the editor they’re looking for is Evil. That said, the vanilla Emacs keybindings have been burned into my muscle memory for decades.
I recently got a hand-me-down Mac after my previous one was stolen and thoroughly destroyed a year ago. I forgot how wonderful it is that all of the standard Emacs key bindings (e.g. C-a = home, C-e = end, etc.) are baked thoroughly into the OS X input handling layer.
IMO they implement just enough to be a kind of uncanny valley; it tricks you into thinking you can use your muscle memory, and then every few minutes you try something it doesn’t know about and get the software equivalent of the feeling of stubbing your toe.
Emacs predates read line by over a decade. GNU Emacs predates readline by several years. Readline supports both vi and emacs-style editing depending on the contents of .inputrc.
I, on the other hand, like the Emacs keystrokes and will continue to be happy Evil exists because the more people use Emacs, the more likely it is that those keystrokes will continue to be available in the context of a good editing environment with a good extension language.
I really like this because the “Fundamentals” and “Additional Topics” sections are really well-written and cover a lot of useful things that have, in time, begun to get lost among all the articles about how you can read mail, browse the web, manage your git tree and walk your dog with Emacs.
In the last year or so I’ve been using VS Code more and more often, in part because that’s what the world is moving to and I have to know it if I’m to walk a mile in an intern’s shoes, but also because my Emacs environment for Rust programming is a little high-maintenance for my taste, at least for now.
I expected I would miss many of Emacs’ packages. I didn’t, VS Code’s extension marketplace is huge. But much to my surprise I ended up missing editing features. I wasn’t even aware how much I was relying on registers, macros and recursive editing. Not having them is like I’m programming with one hand tied behind my back.
This is a very interesting read even if you don’t really care about tooling and are just interested in program extendability and/or text editors in general.
What’s super interesting is that much of the sentiment expressed in the early bits of the article also applies to modern Neovim now that all of its APIs have been converted to Lua.
It’s still “turtles all the way down” just a different species :)
I switched to Emacs from Vim a couple of years ago. To ease the transition I chose spacemacs because it offered evil-mode and had a lot of pretty good settings. However, it’s dog slow, even on a relatively beefy Macbook Pro. I even switched to using the latest version with native-comp, but no dice. Sometimes it even completely hangs when I edit python or go files. Have other people encountered the same issues? How do you fix them?
I’ve heard similar complaints from Spacemacs users; Spacemacs brings in so many things that it makes it hard to tell where a specific problem is coming from. Luckily it’s easy to use evil-mode on its own.
Have you tried Doom Emacs? I had similar issues you describe with Spacemacs, which caused me to switch to vanilla vim (yikes). A friend introduced me to Doom and it’s been pleasant. It feels batteries-included like Spacemacs, it has good evil support, and its rough edges haven’t been as rough as Spacemacs’s. My config files are pleasantly short and I believe that the legitimate configs (e.g. keybinds) outweigh the hacks (e.g. lsp parse failure workarounds).
My biggest issue so far is with lsp-mode choking on some inputs, but I kind of think it’s my fault.
My personal laptop is a 6-year-old Thinkpad running Linux, and Spacemacs is not at all slow. But six months ago I started a new job and they gave me a Macbook Pro M1 for work. I’ve been mostly impressed with the MacBook…superb screen, amazing battery life, and generally quite fast… except emacs seemed almost painfully slow, especially with Spacemacs. Installing emacs 28 and compiling all elisp to native code does improve things quite a bit, though.
I just have to ask the “is it plugged in” question: Have you checked you’re running an M1 build and not x86 via rosetta? (Some things get really slow when run via rosetta.)
How good are you with Emacs Lisp? Emacs has a built-in profiler – actually, there were two at one point! – which might at least help you figure out if there’s a specific culprit there, or if this is… just how fast the whole thing goes.
Folks in the Spacemacs community might also be able to help. I’m not familiar with it and I don’t use large configuration frameworks, but I get the feeling they have a very active community behind them.
Not to the same extent but I agree that Emacs is quite slow… for a text editor.
Since it does so much more and is a Lisp interpreter underneath I guess that’s understandable, though still annoying.
The thing that first attracted me to Emacs is the reason I stopped using it. It’s described wonderfully in the introduction:
It’s not really a text editor, nor an IDE. It’s really the last remaining Lisp Machine, a synergistic system that you live in, which replaces most of the dozens of single-purpose applications you’d otherwise be using…
The more things you do in Emacs, the more those things multiplicatively enhance each other.
The problem I found is that, obviously, you only get these benefits when you stay in Emacs. That’s fine as long as Emacs offers good alternatives for all of the “single-purpose applications you’d otherwise be using”.
Unfortunately, I have found that it doesn’t. The example that surely applies to almost everyone, as this document admits, is the web browser. I would actually be very happy to use w3m if I could - I’m a grumpy curmudgeon who preferred the web when lynx was my only browser - but that’s just not viable today. My work requires me to use all sorts of awful web apps and, increasingly, I can’t use my bank’s website or even pay my utility bills without running Chrome or Firefox.
But it’s not just web browsers. Most of the Emacs alternatives to single-purpose applications are worse than those single-purpose applications are for their single purpose.
I’m hopeful that the Debug Adapter Protocol will do for debugging what LSP has done for semantics-aware editing… but Emacs cannot compete with a good debugger right now (and it certainly hasn’t been able to for the last twenty years).
Web browsing and debugging are very generic capabilities: I would expect them to be in the toolkit of almost all software engineers. The problem is more acute with specialist software. If a tool is both non-trivial to implement and not used by 90% of Emacs users, there is little chance that Emacs will ever offer a viable alternative to single-purpose applications.
I’ve hit this problem in pretty much every job I’ve had since graduating university. These days I find I usually have multiple applications open at the same time: a modern web browser, a decent debugger, Ghidra, some sort of profiler, a text editor, and probably some vendor-supplied proprietary rubbish too.
What I really want is a computing environment that makes it easy to move data around between all those different applications.
Emacs provides a beautifully consistent UI with first-class composition between different applications… but only those applications that run inside Emacs. So that’s no good.
Old school UNIX (or, better, Plan 9) provides an excellent environment for plumbing together multiple single-purpose applications… but it only works if all the applications are designed to work in the same Unixish way. Plan 9 didn’t catch on and we never got a modern equivalent to the 1980s UNIX experience.
These days, I’m happy if I can just get a consistent UI and functional copy & paste.
Emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. — Neal Stephenson
Was not aware of that quote before. Nice.
It’s from his In the Beginning… Was the Command Line essay.
Quite so, and that essay is what made me try to learn Emacs.
I failed.
The UI is terrible and now, over 30 years since CUA imposed a necessary and very welcome degree of harmony and standardisation on text-mode UIs, I am not learning a another awful 1970s-style UI, no matter how much power it offers me.
Use the same UI and the same terminology for it as every graphical app in the world since before many current FOSS programmers were born, or GTFO. Alt-F opens the File menu, alt-E opens the Edit menu. Ctrl-X is cut, Ctrl-V is paste, Ctrl-C is Copy. Ctrl-P is print, not that that matters much any more. Ctrl+left & right cursor keys moves a word at a time.
In Emacs,
ergo-emacs-mode
fixes a lot of this, but not all.I don’t have a Meta key. Neither do you, and neither do any of the Emacs developers. The last new production keyboard with a Meta key was made about 40 years ago or something.
Any keyboard younger than human middle-age has Alt, Ctrl, Shift and maybe Super/Windows/Command keys and nothing else.
A “window” is a region of the screen belonging to one program with a title bar at the top.
Times change. Language changes. Successful computers adapt to this. If it doesn’t, if it maintains its own terminology from 50 years ago, then fine, programmers from 50 years ago can keep it.
Secondly, I am not a programmer; I write English, not any programming language. There is so much bloat aimed at programmers in Emacs that it totally hinders learning and using it, and I can’t find any way to turn it all off. For example, I don’t want syntax highlighting, unless it understands the syntax of English.
I am 100% perfectly delightedly happy for all this stuff to remain there as an option for those who know it. All the hideous old cruft can be enabled if so much as an ~/.emacs file is present, or something.
But if its fans want it to survive and thrive, it needs new users and new maintainers, and that means meeting 21st century computer users in the middle. Adapt to the terminology that has become standard since, you know, MS-DOS in 1981 and the Macintosh in 1984. Adapt to the keys present on every keyboard.
I am typing on a 32 year old keyboard right this second, and it does not have a Meta key. It has Alt and Ctrl and it doesn’t even have Windows keys because it predates Windows 95.
This stuff is old now. Adapting to it is not heresy. It’s not some horrid recent thing. These are the established standards that I learned when I started in this industry in 1988 for hypothetical deities’ sake.
Emacs is user-friendly. It’s just particular about who its friends are.
C-u 1 0 0 0 M-x hail-emacs
!It is strangely appropriate to remix a Unix meme into an Emacs one. Well played.
But of course the thing is that Unix has grown up and become a lot more friendly. A modern Linux distro is pretty much up there with Windows and close to macOS.
The result, or one of the results, is that there are orders of magnitudes more xNix users now than there’ve ever been before. ChromeBooks sell in the hundreds of thousands a year, and Macs aren’t far behind, and they’re all Unix machines. UNIX™ in the case of macOS.
Wouldn’t it be good for Emacs if the same happened to it?
If you don’t program, you probably don’t need a programmer’s editor.
Emacs is meant to be customized to your needs, and be self documenting. Which it is.
Oddly enough, I realise that. But the point that is clearly spelled out in the Neal Stephenson essay we’re commenting about here is that many feel that it is also the ultimate text editor. That’s the quote, right there, 3 comments up. If you haven’t, you really should read the essay. It’s one of the most insightful pieces of mainstream (non-technical) writing about operating systems ever, IMHO.
That is my point. If it’s so customisable, then it should be easy to just make some modest tweaks so that it conforms to the terms and the keystrokes that are now standard from Notepad to VS Code to macOS Text Editor to Kate… and if they are only the default for new users who don’t have an existing config file, this won’t hurt or even inconvenience the experts.
Secondly, while I’m a journalist again these days, I spent most of the last decade being a technical writer. You may not know this, but not only programmers use programmers’ editors. A lot of other non-development staff in multiple companies use code editors to write in; it is an entire philosophy of technical writing, called Docs as Code, used from Red Hat to SUSE to Cloudflare.
Tools such as Markdown, AsciiDoc, and Restructured Text, all flow from the docs-as-code camp.
It is easy to rebind the keys? Maybe you should use a less configurable editor.
Not everything has to be everything to all men. In particular by having the ability to be anything, emacs requires you to have the ability to use that configurability. In a similar way, I’m terrible at making things with basically any art supplies. And yet, people continue to use and pay for these things.
If you can’t find an editor that works for you, ask a colleague or friend what they use. Using any editor is a skill, and as such needs to be learned, and is learned best when taught.
Emacs shines for me because I can use it for any editing, and don’t ever need to learn a new editor (instead my effort goes into customizing particular modes). As far as I can tell, vim users value the same thing. If you don’t actually need to edit lots of types of code, then maybe emacs isn’t for you.
VSCode in particular seems to be an attempt to occupy a slightly different point on the configurability/genericity spectrum that is a bit more rigid overall but also requires creating a language server to add a new language (even more difficult). It’s OK for that to be better for your needs - it’s certainly a good editor for people to invest their time in learning that will probably work well as a life long editor for lots of people.
You don’t seem to be reading what I wrote.
I am not saying it needs to be easier to use. That ship has sailed. There are probably 1000 editors that are easier to use.
I’m not saying it needs to be a word processor. That is not its purpose.
I am saying it should use the same standard UI that basically all other text editors settled on ~30 years ago, except for a handful of weird outliers in the Unix terminal (Vi, Joe, Pico, etc.)
That if it did, it would be easier for newcomers to pick it up, and that would win it more users, and help ensure its ongoing health, vitality, maintenance, and ongoing development.
There really isn’t a downside to this. Those who know how to use it already do and would not be inconvenienced.
Yes there is. CUA bindings overlap with the standard Emacs bindings in many ways. They are strictly worse than the Emacs bindings. If anything, more non-Emacs programs should abandon the CUA style.
There may be a decent argument for switching to
vi
bindings, but I don’t think that there is a great one for switching to the CUA ones.That is so laughably absurd I am amazed anyone could say it and really mean it.
The war is over. It was over last century. There is a standard set of keystrokes, of terminology. Keyboards don’t have Meta keys. I am 55, I have been using computers for some 45 years, and I do not believe I have ever seen a single computer with a Meta key. Since the mid-1980s, it’s been Ctrl (“control”) and Alt, maybe Apple or Command or ⌘, or Windows. I’ll allow “Super” for this since there is no single alternative.
This is so long forgotten now that authoritative sources get it wrong, e.g. this:
https://www.w3schools.com/jsref/event_key_metakey.asp
« On Windows the META key is the Window (⊞) key. On Mac machines the META key is the Cmd (⌘) key. »
That is flat wrong. Alt = Meta. Windows/Cmd = Super.
This is a real, serious issue, and just dodging it on the basis of “we’ve always done it this way” is beyond wrong-headed into risible.
Das ist nicht nur nicht richtig; es ist nicht einmal falsch!
On a GUI, which is most of them, programs open in windows. The window may be full screen, but it’s still a window.
There are standard keystrokes for word left, word right, select forward, select backwards, select upwards, etc. etc. Ditto for file open, file save, print, cut, copy, paste.
It’s a written formal documented standard from forty years ago.
It is obeyed by Windows, OS/2, DOS since 4 or so, classic MacOS, Mac OS X, every graphical desktop on every Unix in the world, every mainstream GUI text editor on every computer with a keyboard.
The Emacs adherents remind me of Shoichi Yokoi. He was the Japanese sergeant who remained in hiding on Guam for 28 years, until 1972.
It’s all over, folks. The side that won aren’t the baddies any more. They never were. They just wanted everyone to be able to talk to each other using the same words and the same commands.
I am really sorry that you are still hiding and pretending that you’re still fighting in the war, but it’s over. Peace broke out in 1987, when Richard Stallman was 25 years old. Within about three years, the last holdouts gave up.
Vim and Emacs may still be sweating in caves on mountains somewhere but the war is finished.
[Comment removed by author]
Started with Vim, went to Emacs, installed evil-mode to get the best of both worlds, and have been using that for the last few years now. Emacs is really a treat.
Right, when people say Emacs is a good operating system, but needs a good editor, the editor they’re looking for is Evil. That said, the vanilla Emacs keybindings have been burned into my muscle memory for decades.
“Emacs does have a good text editor in it; I’ve just decided not to use it.” – Statements dreamed up by the utterly deranged (including myself)
I recently got a hand-me-down Mac after my previous one was stolen and thoroughly destroyed a year ago. I forgot how wonderful it is that all of the standard Emacs key bindings (e.g. C-a = home, C-e = end, etc.) are baked thoroughly into the OS X input handling layer.
Interesting definition of “all”. =)
IMO they implement just enough to be a kind of uncanny valley; it tricks you into thinking you can use your muscle memory, and then every few minutes you try something it doesn’t know about and get the software equivalent of the feeling of stubbing your toe.
These shortcuts actually come from a C library that I think predates Emacs called
readline
. Browseman readline
.Emacs predates read line by over a decade. GNU Emacs predates readline by several years. Readline supports both vi and emacs-style editing depending on the contents of .inputrc.
This is true. However, Ctrl-e for “end”, ctrl-a for “home”, etc. also pre-date Emacs. They were present in TECO first.
I, on the other hand, like the Emacs keystrokes and will continue to be happy Evil exists because the more people use Emacs, the more likely it is that those keystrokes will continue to be available in the context of a good editing environment with a good extension language.
I would love to have this in printed book format.
I would also love a printed format! FWIW there are also pdf and epub versions of the book.
Thanks for these links!
And that is a pretty PDF as well.
I really like this because the “Fundamentals” and “Additional Topics” sections are really well-written and cover a lot of useful things that have, in time, begun to get lost among all the articles about how you can read mail, browse the web, manage your
git
tree and walk your dog with Emacs.In the last year or so I’ve been using VS Code more and more often, in part because that’s what the world is moving to and I have to know it if I’m to walk a mile in an intern’s shoes, but also because my Emacs environment for Rust programming is a little high-maintenance for my taste, at least for now.
I expected I would miss many of Emacs’ packages. I didn’t, VS Code’s extension marketplace is huge. But much to my surprise I ended up missing editing features. I wasn’t even aware how much I was relying on registers, macros and recursive editing. Not having them is like I’m programming with one hand tied behind my back.
This is a very interesting read even if you don’t really care about tooling and are just interested in program extendability and/or text editors in general.
What’s super interesting is that much of the sentiment expressed in the early bits of the article also applies to modern Neovim now that all of its APIs have been converted to Lua.
It’s still “turtles all the way down” just a different species :)
I prefer Vim.
Well, these days I prefer Kate.
I switched to Emacs from Vim a couple of years ago. To ease the transition I chose spacemacs because it offered evil-mode and had a lot of pretty good settings. However, it’s dog slow, even on a relatively beefy Macbook Pro. I even switched to using the latest version with native-comp, but no dice. Sometimes it even completely hangs when I edit python or go files. Have other people encountered the same issues? How do you fix them?
I’ve heard similar complaints from Spacemacs users; Spacemacs brings in so many things that it makes it hard to tell where a specific problem is coming from. Luckily it’s easy to use evil-mode on its own.
Have you tried Doom Emacs? I had similar issues you describe with Spacemacs, which caused me to switch to vanilla vim (yikes). A friend introduced me to Doom and it’s been pleasant. It feels batteries-included like Spacemacs, it has good evil support, and its rough edges haven’t been as rough as Spacemacs’s. My config files are pleasantly short and I believe that the legitimate configs (e.g. keybinds) outweigh the hacks (e.g. lsp parse failure workarounds).
My biggest issue so far is with lsp-mode choking on some inputs, but I kind of think it’s my fault.
My personal laptop is a 6-year-old Thinkpad running Linux, and Spacemacs is not at all slow. But six months ago I started a new job and they gave me a Macbook Pro M1 for work. I’ve been mostly impressed with the MacBook…superb screen, amazing battery life, and generally quite fast… except emacs seemed almost painfully slow, especially with Spacemacs. Installing emacs 28 and compiling all elisp to native code does improve things quite a bit, though.
I just have to ask the “is it plugged in” question: Have you checked you’re running an M1 build and not x86 via rosetta? (Some things get really slow when run via rosetta.)
[Comment removed by author]
How good are you with Emacs Lisp? Emacs has a built-in profiler – actually, there were two at one point! – which might at least help you figure out if there’s a specific culprit there, or if this is… just how fast the whole thing goes.
Folks in the Spacemacs community might also be able to help. I’m not familiar with it and I don’t use large configuration frameworks, but I get the feeling they have a very active community behind them.
Not to the same extent but I agree that Emacs is quite slow… for a text editor. Since it does so much more and is a Lisp interpreter underneath I guess that’s understandable, though still annoying.
The thing that first attracted me to Emacs is the reason I stopped using it. It’s described wonderfully in the introduction:
The problem I found is that, obviously, you only get these benefits when you stay in Emacs. That’s fine as long as Emacs offers good alternatives for all of the “single-purpose applications you’d otherwise be using”.
Unfortunately, I have found that it doesn’t. The example that surely applies to almost everyone, as this document admits, is the web browser. I would actually be very happy to use w3m if I could - I’m a grumpy curmudgeon who preferred the web when lynx was my only browser - but that’s just not viable today. My work requires me to use all sorts of awful web apps and, increasingly, I can’t use my bank’s website or even pay my utility bills without running Chrome or Firefox.
But it’s not just web browsers. Most of the Emacs alternatives to single-purpose applications are worse than those single-purpose applications are for their single purpose.
I’m hopeful that the Debug Adapter Protocol will do for debugging what LSP has done for semantics-aware editing… but Emacs cannot compete with a good debugger right now (and it certainly hasn’t been able to for the last twenty years).
Web browsing and debugging are very generic capabilities: I would expect them to be in the toolkit of almost all software engineers. The problem is more acute with specialist software. If a tool is both non-trivial to implement and not used by 90% of Emacs users, there is little chance that Emacs will ever offer a viable alternative to single-purpose applications.
I’ve hit this problem in pretty much every job I’ve had since graduating university. These days I find I usually have multiple applications open at the same time: a modern web browser, a decent debugger, Ghidra, some sort of profiler, a text editor, and probably some vendor-supplied proprietary rubbish too.
What I really want is a computing environment that makes it easy to move data around between all those different applications.
Emacs provides a beautifully consistent UI with first-class composition between different applications… but only those applications that run inside Emacs. So that’s no good.
Old school UNIX (or, better, Plan 9) provides an excellent environment for plumbing together multiple single-purpose applications… but it only works if all the applications are designed to work in the same Unixish way. Plan 9 didn’t catch on and we never got a modern equivalent to the 1980s UNIX experience.
These days, I’m happy if I can just get a consistent UI and functional copy & paste.
This is very, very good, thanks! I wish I knew this book years earlier!