How I am deeply integrating Emacs
joshblais.com
joshblais.com
I think this is a fallacy. If you approach the question of how these people achieve the things they do with a bias towards tooling then you'll come to the conclusion that it plays a big role in their success.
In reality, many of these folks start with a very strong drive to achieve something and then the rest sort of follows. If you want to be a world class musician, start practicing an instrument. Ideally fall in love with music. The rigorous and meticulous practice routine comes later.
In other words: you can have the world's best tooling that gets out of the way, but you're still as unmotivated to do anything as before.
I think it's a cool idea and it sounds like a fun and creative endeavor. I don't want to talk it down. But I also wouldn't want folks to get the, in my opinion, misguided impression that "tooling -> success" is the correct order.
A really good guitar is easy to miss notes on. Precisely because good guitarists don't typically miss.
Now, I think you could reword a little bit. The best performers know their tools very well. So well, that they often "just disappear" for them. This does require some level of quality in the tool. But requires a ton of effort from the performer, too.
There is also the case that once your entire livelihood depends on something, consistency and muscle memory matter a lot. Lots of world-class athletes, drivers, and performers probably use tools that closely resemble the tools they learned and trained with their whole lives so they would probably seem kinda anachronistic to a newcomer.
I think YuukiRey's point is that this is not true. The bottleneck for people to do their absolute best is almost never tool-induced friction, until you've already built a strong pre-existing skillbase. Overwhelmingly it's motivation, interest, time, energy, etc.
In theory tools can help with this. In practice usually the pursuit of tooling ends up being a distraction. This is how you end up with the (overly derogatory) idea of GAS, "Gear Acquisition Syndrome." The equivalent of this for digital things is e.g. the writer who spends money and time trying to find the perfect text editor paired with the perfect keyboard paired with the perfect monitor etc, instead of just writing. There are of course exceptions where tooling is really the main unlocking feature, but those are far and few between.
In fact what I get from YuukiRey is the opposite of this:
> Yeah, the absolute top-tier max-talent people can do well regardless
Rather it's that the best tooling only really makes sense for top-tier people, because for almost everyone else the tooling is not the bottleneck.
I have recorded hundreds of songs using digital audio production software since ~1999. Switching to Logic Pro unlocked the opportunity for me to work WAY more effectively than a shareware tracker software I was using before (and Fruity Loops after that), in fact allowing production techniques that are literally impossible with a tracker. Not just large-scale features, but minutiae in how the interface works, "intuitiveness", ease of access like a single key-press to enter a certain editing mode, things like that.
When I am working with my mind and trying to be creative, every millisecond spent thinking about stupid UI quirks/peculiarities takes away from the part that actually matters: creating.
If the UI is obtuse, and I can't figure out how to employ a certain technique, the tool is hampering my progress. Conversely, a thoughtful feature in a tool can boost productivity and boost the success rate of reaching a "flow state"[0]. One example of this: there's a common technique to record multiple takes of the same segment of instrumental performance or vocals, and then layer those multiple recordings together to give more dynamism and depth to the sound. Infected Mushroom uses this technique a lot[1]. In Logic Pro 10 or so, they added built-in support for doing this, making it super easy to quickly/successively record multiple takes[2]. I don't know what other DAWs did this at the time, but if you're just learning, this is a really nice production process surfaced in a very low-friction way. Otherwise you are making a new track, recording, trying to line it up properly, making a new track, recording again, lining it up again, etc. It's also not even obvious that this is something you could do, but because Logic made it an actual built-in feature, its very existence also acts as a form of "tutorial" if someone is just exploring the UI or reading the documentation.
So, yeah, as a pretty amateur studio producer at the time, the "best tooling" allowed my skills to improve by a gigantic margin, compared to the slow progress I was making with inferior tools before that. I can't agree for a second that tooling doesn't matter or only matters for people at the top of their game.
[0] https://en.wikipedia.org/wiki/Flow_(psychology)
[1] https://www.prosoundweb.com/exclusive-interview-production-t...
[2] https://support.apple.com/en-ca/guide/logicpro/lgcpb19806af/...
That's fair. I was mainly pointing out that "a bit differently" is significantly underselling it. You are basically of the opposite point of view.
Some are just fine with a standardized but unoptimized tool while others are fascinated by building their own high-flying TUI. The journey is the destination. If all you create is a config file, it still counts.
E.g., quick high-level examples: Photograph invented led to Impressionism, Andy Warhol's entire oeuvre. Today one of the most talked about artists is Beeple (technology-forward in distribution medium, tooling, and even practice techniques [e.g., "dailies"]).
Music is probably where this is the most profound, take the trajectories of Miles Davis and the Beatles, both started their career with a fledgling recording industry, ended it record in sophisticated studios using instruments and studio techniques that didn't exist a mere 5-10 years earlier.
In electronic music this is even more pronounced, e.g., Native Instrument's Massive synth facilitating dubstep is a nice clean example, but if you've followed electronic music overall the connection is obvious. E.g., what dates most pre-2000s era music is that today musicians use DAWs whereas before it was less powerful hardware devices that had a more specific sound (and other arrangement and composition limitations).
This actually feeds into one of the points you made: Being successful at art (or anything really) has a lot to do with how excited and motivated you are to pursue it. It's easier to be excited if you feel like you're exploring new territory, ripe with untapped potential, and that's historically often been unlocked by technology. Whereas if you keep comparing your solos to John Coltrane when you're learning the saxophone, that's going to be demoralizing and you'll feel like you'll never get there so why bother trying. There's also diminishing returns, e.g., that music territory has been so thoroughly explored now, so the ROI on developing that specific skill (playing jazz at that level) has been reduced, because so much of that artistic space has already been explored.
If you tie that all back to the art itself, I'd assume today that we already have saxophone soloist who are more technically skilled than John Coltrane, e.g., the music theory is better understood, and we've had decades of iteration to improve practice techniques (there are tons of books and studies on this subject now). But you can't replicate the sheer excitement that those musicians must have felt as they unlocked new music possibilities by iterating on music theory (a form of technology), and recording as a new medium to share and learn from.
To be clear, most of what you've said I'd agree with, but I'd add more nuance like: Leverage technology to make the act of creation as exciting for you as possible, but the main goal of the excitement is to keep yourself practicing and improving. And also look for untapped potential (e.g., a specific example that's relevant today, I think GPU-based rendering is still under-explored today Beeple has been able to leverage this in his art, but I think the big barrier of entry [probably ~$10,000+ for hardware/software over the course of a career] means there's untapped potential there.
E.g., Daft Punk on well-tread territory due to the accessibility of technology https://pitchfork.com/features/lists-and-guides/9277-the-yea...:
> Technology has made music accessible in a philosophically interesting way, which is great. But on the other hand, when everybody has the ability to make magic, it's like there's no more magic—if the audience can just do it themselves, why are they going to bother?
I think the point of the author in your quoted text is that you want to avoid the tools getting in your way. If you're a writer, you become successful by writing good stuff. That's harder to do if your OS crashes and you have to click through a bunch of menus while you're writing. That's the reason so many bloggers adopted markdown 10-15 years ago - writing in plain text meant the tools got out of their way. It's not about the tools making you more productive, it's about using tools that don't make you less productive.
"If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution."
But I don't see where the author is committed to such a thesis in the quote you provide.
As far as as I can see, they are not even committed to best tooling being a necessary condition for success.
Anyway, I began learning Emacs commands in the Emacs tutorial on that Braille Plus, , and they made sense to me. Unfortunately, Emacspeak only really works well on Linux and Mac, not Windows where all the blind people are. Speechd-el only works on Linux, since it uses Speech-dispatcher. I got Speechd-el talking on Termux for Android last night though, although it was rather laggy between key press and speech. Emacspeak development has paused, though, and Speechd-el seemingly hasn't been updated in half a year. Emacs itself has a lot going on for a normal screen reader to interpret which is why Emacs-specific speech interfaces are so useful.
A few examples:
* On Windows, with Windows Terminal and NVDA screen reader, arrow keys read where the cursor is, but C-n and C-p, C-f and C-b, all that, NVDA doesn't say anything. This is with the -nw command line option because the GUI is inaccessible. * Now, if I do M-x, it does say "minibuf help, M-x, Windows Powershell Terminal". From there, I can do list-package and RET and use arrow keys to go through packages, but N and P don't speak even though I know they move between packages. So it seems like the echo area works. * Programs like the calendar, though, really doesn't speak well with a screen reader. It just read the line, not the focused date. Using left and right jst say "1 2 3 4 5" etc. So custom interfaces don't work well. I shudder to think how it'd read Helm.
Lol maybe I can get AI to make a good speech server for Emacspeak for Windows.
I really want to make my web apps as accessible as possible for the blind.
Could you tell me what are the worst and best practices in this regard?
Any article you recommend?
And how could I test accessibility of my web apps, for the blind? Perhaps try to navigate it with screen reader and keyboard only?
As the years go by one realizes that even these “features” like Org, Dired, etc are just illusions in some sense. They’re just Elisp code someone else wrote and put a name on. You can take or leave them or write your own code that changes/advises/customizes them.
It’s all up to you. You don’t need a blessed “plugin” architecture, some PM at IntelliJ’s permission etc
At some point one realizes the “visual shell” nature of Emacs. Every single piece of text on screen can be programmed to “mean something” (see also: “recognizers” from human interface research) and have actions taken on it either by the editor itself, or external processes / scripts you call with a command. If it’s common enough, make a key binding. It’s your house, do what you want
Depending on how you set up your environment, you may never have to look at text again that you do not have this level of power over. You are no longer at the mercy of “application developers”
I’ve been using it since 2005. Guess how many of 2005’s popular editors even still exist
My recommendation to anyone trying to actually learn is start with the full vanilla config, weird default keybindings, etc, go through the built in tutorials, and only add things to your config that you write and understand yourself. Understand it in its own terms. The plethora of packages, etc have “cool features” but impede learning by adding mountains of complex dependencies that are opaque to the beginner and cause confusion IMO
With that requirement going away, I left Emacs behind.
A lot of people hate that, they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent, and zero options to tinker with. It should just work, and preferably never change.
A middle ground are the browsers that just work out of the box, but can be heavily customized by extensions. MS Office is another example.
It seems a curious attitude for a developer, though. My curiosity about how things work and the joy I get when I make a computer do the specific thing I want it to do for me are the reasons I program for a living.
But that's just culture, and quite easily moldable. Lots of people would also rather gamble watch smut all day, but we decided that it's not the best way to go about life... so we set up a system (school) to manage their learning process, and shepherds them for well over a decade, and then involves them in the economy and in society. Likewise we have cultural mechanisms which try to ensure that people learn essential skills related to nutrition, mobility, relationships, etc.
A lot of this has been eroding in recent years under the banner of convenience, and will likely have pernicious consequences in the coming decades. I posit that letting the insidious patterns broadly drive our approach to computing is similarly dangerous.
A lot of people don't even know how to use their tools properly. I remember when I was teaching a number of Perl courses to programmers, they where joking about me using emacs while they where using vi or vim.
But while I watched them while they did their exercises, I constantly heard the "bing" sound when the cursor hit the end of the line. Why? Because they pressed the cursor key and waited for the cursor to travel to the end of the line, then chynged to insert mode to append stuff.
Even I, a humble emacs user, knew that there was a vi command to jump to the end of the line and append.
Somehow in the same vein, some people prefer to write in C and tell the machine what exactly it must do, on a very low level, instead of picking an abstraction-rich language like Typescript or C++ or, well, a Lisp, where you typically operate in abstractions which you need to tweak to express your solution elegantly and correctly, but not very directly.
It gave me orange. I wanted lemon-lime. Another one swallowed my coins.
But to be pragmatic, many tasks need more than one thing to be done (I think most of us compose our e-mail in a program which sends said e-mail out as well, for example), so the inflexible tools can be insufficiently convenient at times.
Also, consider the humble scissors. They do one thing and do it well unless they're the wrong handedness. Try using a right-handed pair with your left hand, it's terribly unwieldy.
That is Emacs. You just have to drag the relevant up first and push down the irrelevant.
The thing is in Emacs, most utilities don’t want to presume how you would want some feature. Even if they do have defaults, they are suggestions at most. Instead of getting a tools that you have to learn and conform too, you get the template/idea/inital_version of a tool, and you make it your own
And there’s the whole idea of integrating stuff instead of isolated utilities.
Don't waste my time with 70s "ergonomics" (if it can even be called that)
The comparisons with art seem almost to the point of offense to me. You're not building art, you're just building another yet plugin for emacs to do what other people do in maybe 5% less efficient ways but won't spend 2 days automating it
The thing is that, there’s enough packages built-in and by third-party, you never really write your own. My whole config is pretty much setting options and linking packages together.
Emacs changes big O. It is not about changing constant factor. If you need N commands with M features then you can implement and combine them in emacs in O(N+M), to get O(N*M) custom commands.
For example, if you need “Search” feature then you can use it everywhere. It can help find you a file in Dired buffer. It can help you find a git chunk in magit. It can help you find todo item in Org mode, etc. It like having a separate `uniq` command instead of implementing it for each shell command (`sort -u` vs. `sort | uniq`). Another example, having `repeat <N> <cmd>` to repeat `<cmd>` command `<N>` times in zsh vs. implementing `<cmd> —repeat <N>` for each command.
The difference is linear vs. quadratic. If you need to do 1000 actions that can be decomposed into 100 commands with 10 features each then in emacs then you need to know and understand ~100 things vs. 1000 in less customizable environments.
For someone not good with the keyboard, it's probably a nightmare. I suppose it's good for power users and terrible for casual users, and I don't know if there's any way to really build one user interface that works equally well for both, it's usually a compromise.
The next best thing I love about Emacs is that I can do anything conceivable with code. This one is an even larger gap between power users and casual users.
I think tools like that are just fated to only attract a select few.
(xterm-mouse-mode 1)
(global-set-key (kbd "<mouse-5>") 'scroll-up-command)
(global-set-key (kbd "<mouse-4>") 'scroll-down-command)
(global-set-key (kbd "<wheel-up>") 'scroll-up-command)
(global-set-key (kbd "<wheel-down>") 'scroll-down-command)I tried it for a while, after seeing my Eve Online friend skipping through tasks at a rate of knots without any mouse movement. My god the amount of tab pressing I had to do to get anything done was crippling. I might have to jump through 15 times to get to something that would take me less than a second to click.
Fundamentally the mouse is just a form of modal editing. Emacs supports this in spades of course, and god-mode is my modal input minor mode of choice, but clicking to jump to a position on screen can often be a lot faster than I search or avy-jump commands, say nothing about how much gentler on the wrist it is. Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
Then you have the biggest benefit of using the mouse: scrolling around reading code or text while having a drink or snack in the other hand. These days I use a trackball in my left hand. Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Certainly. I wouldn't argue that text editing speed is a relevant bottleneck in software development, actually. To me it's enjoyable and that's a big factor in my productivity, but that's just me.
My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it). The "code the entire environment" thing you mention is another example. Not sure I expressed that point all that well, rereading my comment it almost looks as if I'm trying to start a flame war :D
This comparison of the mouse and keyboard seems to have programmer tunnel vision. Anything involving layout, graphs, media editing (audio, video, image), 3D modeling, and drawing I think we can all agree are better served by the mouse (in tandem with the keyboard). It's really the mouse and keyboard together that's made the computer such a successful creative medium. Programming seems to me like a bit of anomaly in that it's one of the few creative tasks that doesn't benefit greatly from a mouse.
People with RSI from constantly reaching for a mouse.
I love emacs because I can do everything with the keyboard. It is faster and a lot easier on your body long term. My advice, start young. Keep your keyboard directly on your lap and use a ortholinear plank keyboard so your fingers don't have as far to travel. I was skeptical at first, but I will never go back.
I literally went to an orthopedic specialist recently for overuse of the left alt key causing me pretty notable pain in my thumb.
My primary mouse is a trackball one, because I have pain in my arm (elbow and shoulder) when I use a regular one on a desk.
I will maybe get a split keyboard in the future. But I did get a mechanical one because of key travel. And I touch type, so I spend less time on the keyboard itself.
I had RSI issues early in my career and this advice alone really helped. Never got the Emacs pinky/thumb. I recently switched to a MacOS and that is giving me thumb issues with the overuse of the Meta button. I now consciously have to force myself to use a different finger when pressing Meta.
Always remember: You have five fingers - no need to keep using the same one/two fingers to press Ctrl or Alt. It will take time getting your brain used to using other fingers for this purpose.
Oh, and yes: Definitely got lots of ergonomic pains due to mouse use. In fact, I changed my career from "regular" engineering to SW engineering partially to avoid having to use a mouse (e.g. CAD SW). And every ergonomist you'll meet will tell you "Memorize keyboard shortcuts and avoid the mouse as much as possible."
And because emacs is under socialized and under adopted the emacs user will still have to use notion or outlook or whatever corporate security requires.
There's no reason a program like Emacs couldn't exist which had something like capabilities baked in, but as it is, every package has access to anything it wants.
My few cents:
Pretty much every ergonomist will tell you that mouse use causes more ergonomic pains than keyboard use. They literally tell you to memorize as many keyboard shortcuts as possible.
> but clicking to jump to a position on screen can often be a lot faster than I search
It can be, but is it the norm? I have a distinct memory - over 15 years ago - of reading a blog post that recommended isearch to move the cursor and realizing how right it was. I suppose not everyone agrees.
> say nothing about how much gentler on the wrist it is
A bad mouse is as bad as bad posture on the keyboard. You only realize this once you're in pain. Not everyone reaches the point of pain.
> say nothing about how much gentler on the wrist it is
You should not be moving your wrist! Move your whole arm. Once again, one realizes this only when you're in pain. Not everyone reaches the point of pain.
> Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
The same argument works for keyboard. If you're going the route of customizing the menu for particular commands, you can also customize the keyboard to minimize the keystrokes for those commands (e.g. via hydra).
Right but that's because their advice is tailored around the "average" computer usage, which is lots of mousing to click around in buried menus and hunting and pecking on the keyboard. RSI is just what it says: Repetitive Stress Injury. The best palliative for RSI is to stop repetitively stressing the same tendons and ligaments. So that means breaking up your keyboarding with some mousing. Alternating which finger and which hand you use. Getting up and stretching and taking breaks. Maybe using some dictation in lieu of using an input device.
If you're writing text, your mousing is mostly going to be scrolling, unlike doing something like CAD or design or illustration. In that context, the context of using emacs, mousing is fine.
And realistically, for my own RSI, exercise was the real solution. Rock climbing increased the blood flow to my wrists significantly. That's probably the only real solution to RSI.
https://sites.google.com/site/steveyegge2/effective-emacs
Get in the habit of using Ctrl-r (isearch-backward) and Ctrl-s (isearch-forward) for moving around in the document. Whenever you need to jump the cursor backward or forward more than about 5 lines, and you can see the target location, you should be using i-search.
To do it effectively, you don't necessarily need to search for the exact word where you want to put the cursor. Let your eye defocus slightly and take in the whole paragraph or region around the target point, and choose a word that looks reasonably unique or easy to type. Then i-search for it to navigate to it. You may need to hit Ctrl-r or Ctrl-s repeatedly if your anchor word turns out not to be unique. But Emacs will highlight all the matches, so if there are more than a couple of them, Ctrl-g out of the search and choose another anchor word.
It's difficult to overemphasize how powerful this technique is, once you've mastered it. Mastering it simply requires that you do it repeatedly until your fingers do it "automatically". Emacs eventually becomes like an extension of your body, and you'll be performing hundreds of different keystrokes and mini-techniques like this one without thinking about them. It's comparable to the hundreds of subtle techniques you acquire for driving a car well.
But generally, please if you believe this provide some kind of source.
you already could though, no? emacs didnt allow you to execute lisp for the first time
Is a bit like having a problem with "ls" and wondering if you could fix it by scanning the source real quick. In emacs, that is often just a keystroke away. In most systems, good luck.
I have a hope for the Common Lisp based Lem. All we need is to coordinate enough signal for potential users to feel it's the right time for their actions. Go star Lem https://github.com/lem-project/lem
I feel the same way about org mode. Nice. Can I use it on a team? Get real. I'd like more embedded data functionality in markdown. It's not XML, and that's good. Org is just weird. AFAIK it's still trying to figure out inline data embedding, so the embedding isn't even that strong. Doing something like exporting with a CSS class around a specific word probably uses some awkward literal syntax instead.
There are consequences to the monastic culture around Emacs. It's really good at holding itself in place. If you don't buy that tradeoff, you need to keep shopping.
I still can't believe we have IRC for grandma (slack) but not emacs for grandma.
People get tied up in the program-ability of it but it's UI and the concept of jettising both the desktop and tty paradigms.
Basically the notes have the same format that org-mode uses to save notes placed in the logbook. But you can also make them as individual TODO headings or whatever. It's all plain text anyway.
I try to empty the inbox.org every morning, I typically have 20-30 entries to go through. Some things matter and are revised and refiled appropriately. The rest gets dumped into a chronological log file for just in case.
edit: btw, it would be cool if I also made a version that would append the content of the phone's clipboard to the transcription, so that I can also catch links and/or bits of text. Or maybe even multimedia, thought I am not sure how I would accomplish that.
I tried to do something similar on my iPhone, but couldn't get a reliable (or any) way to get an rsync script running.
I ended up with pen and paper though, which is best for me all things considered.
Shortcut: https://www.icloud.com/shortcuts/a8a0076cc03f4e699d8ca34bd3d...
My solution is a twilio text number that automatically inserts any texts it receives into the top of my todo.md file. Previously todo.org, until about a year ago.
iOS has ubiquitous support to quickly share to SMS from any/everywhere. It’s easy to send a text to this contact from a Home Screen shortcut, but also also from the share sheet in most every app.
I keep the inbox.org on dropbox, that keeps it synced.
The shortcut is called “longdictate” because previously I had a version that didnt require me to press stop after finishing my thought. Instead it was set to stop recording when I stopped talking. But it misfired too frequently, cutting me off, so I added the button.
I imagine there must be something similar to iphone shortcuts on Android?
What's your take on opinionated distros like Doom Emacs or Spacemacs?
I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.
However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.
And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.
Should I start fresh Emacs install instead?
PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.
But ultimately it's all about tradeoffs and what works for you. You don't necessarily need to go beyond your distro, but if you want to or need to, then that's a good sign to try it
I've tried both Spacemacs and Doom (and others like Witchmacs and Bedrock) and now I'm just using my own 800 line init.el (which does include comments and whitespace so the actual LOC will be lower) and 110 line custom.el (if you set the custom file to a different file than your init then using customize to change settings won't mess things up if you manually edit your init).
If you really like Doom you can try reading its code base, if it's just too much then maybe it would be better to try setting up your own configuration from scratch.
For me the issues with Doom are (a) the complexity as a whole that it introduces, and (b) so many things are already installed/configured that you end up using them without any real "under the hood" understanding which is so essential for customisation.
(macOS users are stuck with the menu bar generally, and that means they're stuck with the Emacs menu bar too. Just ignore it.)
While you're there, get rid of the scroll bars too. They never work properly, and this way you get an extra column or two of text per window.
I don't think the discoverability of all those things is worth giving up in exchange for 1 more line of text, but of course everyone is different and that makes the world such an interesting place.
Almost none of the options bring up a friendly GUI dialog of the sort you might be accustomed to; you're most likely just plonked back in the Emacs frame, possibly in some new window that opened in some random place, that doesn't seem to work quite like anything you've ever seen before, or possibly in the minibuffer, ditto, plus its own set of additional confusing aspects.
So perhaps the suggestion to just dispense with it entirely (along with the toolbar, which I forgot to mention...) was just the thing that got me over this initial notch in the difficulty curve, the bit where I just needed to give up and accept that Emacs was going to be one of those things that was absolutely not like anything else.
(You're not wrong about the discoverability though. I've been using Emacs for 20 years now and I did find a couple of interesting-looking things.)
I've since switched to Vanilla and I've been using ChatGPT to gradually explain and help me integrate the Doom features that I like, so that I end up with a similar base that I actually understand and which I can deviate from where I want to.
Vim is the magic that lets me use all of those for what I want without having to change muscle memory, and Doom just happens to aligns with my needs perfectly on that regard.
I think anyone trying to master Emacs within the lines of this article will be trying to bend it to their particular needs and likely will be annoyed at any opinionated configuration.
The answer to your question will depend if you want to add community extensions beyond what Doom integrates or if you want to personalize Emacs by yourself. The latter will work just fine with leader keys as long as you map them, all Elisp should be still available in pretty much the same way. The former will probably be much harder.
I would say use both. You can run multiple emacs configurations, and you could have your vanilla config which you slowly build as well as Doom/spacemacs where you can see what is possible.
Trust me, move to Google Docs.
This is simply a whole larger and easier universe compared to anything Org-mode will ever evolve to be. Its also backed up online, pictures are embedded in the document itself. And several other features come out of the box. You also don't have spend years learning to use it, and can get productive from minute 1.
If you use vanilla emacs without customization, you are going to have a very basic text editor experience. That is fine if you understand that, and understand that you'll need to start adding your own customizations (like enabling eglot for LSP, and company-mode for code completions, etc) in order to get to an experience closer to what you'd get out of the box in an IDE like vscode.
Some people might see vanilla emacs, assume emacs is just a plain text editor, and go back to their fancy IDEs. For them, distros like doom/space would be good for avoiding that initial shock/disappointment.
Another great use for doom/space is to see what is possible. Figure out what bits you like, and then figure out how to enable them in your own vanilla-based config. Essentially window-shopping for your own emacs config.
But in the end, I'd recommend you eventually get to the state I am in: I started with a completely vanilla emacs and then slowly added the bits that I wanted. That way I have only what I want, and nothing that I don't want. I don't get surprised by unexpected features. My breakages are fewer because I use so few packages. My load times are great because I am not loading a bunch of stuff I don't use. I understand everything that is enabled in my config.
You also might want to check out emacs-solo. It's a config that is built based entirely on built-in packages rather than 3rd party packages. I still use some 3rd-party packages like company-mode but it is good to see just how far you can go with the built-in stuff (for example, you probably don't need projectile, you can use the built-in project.el, and you probably don't need lsp-mode, you can use the built-in eglot): https://github.com/LionyxML/emacs-solo
> Emacs is single threaded, therefore if anything in the system hangs, the whole system hangs
For development work I haven't found this to be an issue. Generally when coding I use very few X apps - pretty much just a web browser and maybe occasionally a PDF preview or docs browser. I don't think I've ever had a problem with the single-threaded behaviour blocking window management there. (And as an aside, while proper threading would be nice for things that actually should be concurrent - such as EXWM's duties as a window manager - I massively prefer emacs' synchronous processing of input over the JetBrains horror of pressing a key combination and then having to wait for some asynchronous UI behaviour to occur, with different outcomes depending on whether the next keypress occurs before or after the UI behaviour the first one triggered.)
For other, more GUI-focused activities I just run a separate (wayland) session.
However, you do need to avoid call-process (spawning blocking processes) as much as possible. Also, my experience with TRAMP has been pretty awful due to the fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145 (literally: TRAMP blocks all of Emacs while waiting on a network connection).
> Maybe in my retirement I will end my career by helping to make emacs + EXWM multi threaded. I am guessing that is a daunting project, but it sure would be fulfilling.
This isn't fixable with threads, unfortunately. The issue is that:
1. Emacs e.g., launches a process with call-process. This blocks EVERYTHING (including other threads). 2. That process wants to map the window but EXWM can't respond to this request because Emacs is blocked. 3. The call to call-process never returns because the process can't create its window.
You'd have to fix Emacs to not block everything in cases like this, but that has been tried before: https://mail.gnu.org/archive/html/emacs-devel/2023-06/msg007...
At this point, I think the right answer is to write a minimal out-of-process window manager (e.g., a wayland compositor).
1. During normal operation, it would behave like EXWM and ask Emacs how to manage windows, etc. 2. In special cases (TBD), it would behave autonomously, acting like a standard floating window manager until Emacs becomes responsive again.
> It is the ultimate sharpening of the axe before chopping the tree[1]
But if part of our axe sharpening is listening to music, reading email, catching up with your feeds and so on then perhaps we need to take a step back and ask if we're just invading our working thought-space with boondoggles.
[1] "Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - apparently Abraham Lincoln.
Tech debt
Sharpening knives leaves mental space for reflection.
It took me about 2 weeks to get productive at first (this was in 2018), and now I use Emacs every day for a wide variety of tasks (programming and notes, mostly).
At first, it is also a good practice not to install any package, and use the built-in capabilities (`magit` and `org-mode` are now part of the default installation) for a while, the time to discover what comes with the "factory defaults".
Also, for some inspirations, watching videos from `System Crafters, Howard Abrams, Emacs Rocks` to see how some people use it.
It can take a while to get used to everything, or to install packages and customize it to what other editors comes with by default, but the reward is worth.
> `magit` and `org-mode` are now part of the default installation)
Org is, but magit is not.
Personally, I am using Emacs for everything related to plain text files. I have benefited at previous jobs massively from already having solved some issues on my own time.
As much as I love the idea of declarative builds, I’m struggling to justify the investment of learning and maintaining Nix for an individual setup. I’ve dabbled with it and mostly encountered footguns.
Whatever makes a nice, clean slab is what I’m after.
imho exwm is imho fundamentally flawed, especially when running emacs or doing emacs stuff inside it. You end up in a battle over keybindings, etc.
I think a better model would be a window manager in a separate process that your emacs elisp processes can communicate with over IPC.
Also, when compared to neovim, the latency for auto-completion (with LSP as a source) is also unbearably slow. Even with libgccjit enabled.
Now I only stick with emacs for org mode. Maybe I'll try it again, but neovim is just faster.
Emacs for me gets slow when syntax highlighting is on and I navigate to a very long line, text-mode does not have highlighting or the slowness. Most emacs slowness is caused by bad plugins, which if you report may be fixed by developers.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
I do sometimes work on files that are 300k lines (don't ask), and while it's mostly fine, once in a while I'll try to use some less common operation that's not very optimized and have to abort it (e.g. don't try to magit-blame that file). But stuff like searching, scrolling, editing, syntax highlighting are all fast.
If I have to open files >100M I sometimes open them in `fundamental-mode`, which turns off syntax highlighting.
For truly large files (gigabytes), there is the `vlf` (Very Large File) package, which doesn't load it all into memory at once, but still lets you search, scroll and even M-x occur (sort of like grep, but more integrated and editable).
Note that this is on Emacs 31 (there have been some major perf improvements in the last three or so releases, and more is coming with the new garbage collector)
In earlier days there were issues with very long lines; these have partly been mitigated in later releases; on the one hand by faster internals, but also a new builtin package `so-long` that can notice very long lines, default 10k bytes, where Emacs probably should give up syntax highlighting etc. to remain snappy.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
I've always found line length the biggest problem. Emacs has never done a fantastic job of handling long lines. If truncated, you can't see most of the content; if not truncated, the performance gets worse with length, and visual-line-mode (essential for dealing with non-truncated long lines IMO) doesn't make it any better.
Performance with large numbers of mostly shortish lines is ok. I've had no serious problems loading 2+ GByte log files (average line length <200 chars) in literal mode. The general performance suggests that Emacs isn't really tuned for editing enormous files, but I've never found things so bad as to be worth switching text editor over.
(though https://www.youtube.com/@emacsrocks has newer stuff by the same person, seems like game dev in clojure and emacs)
This was my aha! moment where I actually watched someone install and use packages and was like oooh yes, this is both nice and will actually be very helpful. And I have been using emacs since 1998! I find most package pages tell you a lot about the how, but very little about the why on you would want to use them.
Now, this is not a "we need to favour vim over emacs". I think this is a stupid war, the vim versus emacs war.
What I mean is ... basically most editors do almost the same exact thing. They look at some buffer for a file and help the user modify this. There is a finite number of operations possible. Why do people keep on re-implementing basic things here? Why can it not be solved once and for all and then everyone uses that implementation?
We really should have that; and then people can decide ON THEIR OWN what kind of editor they want to use. Many years ago I started with crimson editor as my main editor on windows. I have since then hopped to many other editors. My favourite one was oldschool bluefish in gtk2. I am not saying it was perfect, but I found it much easier to go on my poor brain than e. g. remembering all vim shortcuts. But, it would need xorg + gtk2, so if that is not available, then I can not edit things - that's bad. That was (and still is) also one reason why I use e. g. nano. But this in turn requires ncurses and I hate ncurses with a passion (nano is great though, I can recommend it for quick ad-hoc editing; for larger things it is not quite as good, but if you have to just change some value in a config file, nano is really great).
Even then I used only like 20% of what bluefish offered (the newer bluefish releases are also nowhere near as good as the old releases, also because GTK really sucks nowadays). I'd like to cherry-pick on my editor and declare what I want it to be, without needing to implement everything on my own. Why can't we transition into this? Why do we need to reimplement everything almost from scratch? That just makes no sense to me.
We live in the age where AI autogenerates code (which they heavily drew from stealing people's code). Why can't AI autogenerate the best, most perfect editor/IDE?
Step 2. People complain that it's bloated, that they don't want 99% of the optional features in the editor, and that the codebase is a nightmare to maintain.
Step 3. A thousand more editors are created.