> I have seen what people are capable of doing when their tools get out of the way, and they are free to just create. This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
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.
I'd go further. Some of the world's best tooling is only usable by the world's best users. Examples abound on this. The best drivers are in vehicles that I would almost certainly crash. Our best pilots are in planes that I literally don't understand the controls on. (That is true for the cars, too, oddly.)
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.
As you get better at something you become more opinionated at what you need your tools to do. You demand more specific and tailored things from your tools and so you start to lean towards things that are more adjustable.
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.
You made me think of this quote: "If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." - Antoine de Saint-Exupéry
> 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.
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.
I think of it a bit differently: if the tool is getting in the way, this will hamper the effectiveness and raise the barrier for skilled individuals to do their best. Yeah, the absolute top-tier max-talent people can do well regardless, but if the tools are better quality and more "out of the way", this allows a greater pool of people to do their absolute best, with less friction.
> if the tools are better quality and more "out of the way", this allows a greater pool of people to do their absolute best, with less friction.
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.
Russian equivalent of this idiom sounds like "skillful surgeon helps a bad dancer". Even though it sounds confusing, what it really means is "a bad dancer blames his balls"
Right, I get that. That's their opinion, and I was expressing a differing opinion (that's why I said "I think of it a bit differently" lol)
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.
Maybe it's a fallacy and maybe it isn't. But I often hear people say "I don't use tool X because it doesn't actually increase my productivity". X is emacs or debuggers or profilers or Linux or version control or code comments or whatever. And after observing such people work over time I decided that most of them are just trying to justify their laziness. YMMV.
I think this is a bit of an oversimplification, I see art and technology as more like a dance where it's unclear who's leading who.
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.
> 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?
Seems particularly funny in an article about Emacs, a piece of software that lets you get in situations where some portion of your "just create" time becomes "managing my custom emacs, please don't break".
One way to look it is to approach it as a creative practice. A good part of any practice is devoted to developing technique.
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.
I love Emacs. My first intro to it was on the Braille Plus Mobile Manager back in like 2008 or so. That was a beautiful device that ran Linux and was developed for the blind. There's been nothing exactly like it since. The BT Speak is a poor ematation that runs on a Raspberry Pi 4 and is sluggish because Linux accessibility is hard and not optomized for such low-power devices.
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.
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
I’m perfectly happy woth IDEs for some projects, especially at work. But I tinker with enough ecosystems and OS and sometimes you just don’t have any IDEs. On almost all systems, I can copy my init.el and have my tools replicated in a few minutes.
The most seamless capture-from-anywhere workflow I struck upon is to have a shortcut on my phone's home screen. When tapped, it takes my dictation, transcribes it, and saves it to an inbox.org file with an org-syntax timestamp, synced to my main computer.
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’ve relied heavily on seamless capture for a couple of decades, ala Getting Things Done.
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'd be very curious to know more about the shortcut you describe. This workflow would work incredibly well for me. I already have my notes synced via syncthing, and capture with Orgzly Revived, but auto-transcribed captures would be a gamechanger.
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?
This isn't rsync, but you can integrate a-Shell[0] with iOS Shortcuts. You would need to make the syncing happen in the script instead of in the background though. I use a Python script to create aliases for my email this way, so I don't have to turn on wildcard addressing to my inbox.
For me, the power of Emacs is mainly that I can do everything with the keyboard, which is not only much faster, but also - to me - much more enjoyable than going through visual menus with the mouse.
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.
When I got into emacs 20+ years ago the "use only the keyboard" thing was a huge point of pride and to this day I don't understand why. Who cares? I use emacs because I can code the entire environment.
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.
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).
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.
> 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.
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.
> 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
> 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).
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.
I have been coding for so long now that I can't have my keyboard any higher than my lap. I code with it resting directly on my legs. A mouse is right out. Any higher, and my hands turn to clubs.
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.
Alternate between using the left and right Alt keys. The ergonomist's rule of thumb (no pun intended) is to use both halves of the keyboard. So if pressing Alt-x, use the right Alt button, etc.
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."
As the sibling comment put it, that’s when I look into ergonomics accessories.
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.
This is the thing people forget about emacs - it is primarily a lisp environment, entirely programmable. Something one can make their very own. Nothing else comes quite as close, even if the keyboard ergonomics (at least for me) do help to sell it. You can change the workspace to better the workflow in real time, that's the biggest selling feature.
And this is why, even though it is a better OS environment my grandmother will never use it.
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.
I'm not going to argue that emacs if "for everyone" and there's plenty in my own life that I'm happy to accept defaults in. But that said, it's not that hard to glue emacs onto existing tools if needed. If you're in a situation where you can only send emails on a locked down email client you can still script the client through emacs and some glue code. On MacOS, Apple script does wonders and for Windows there's AutoHotKey. Linux obviously is infinitely malleable.
To be fair to corporate, Emacs has a pretty terrible security model.
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.
I think this largely misses the point. It isn't about which out of keyboard vs mouse is objectively better or faster. It's about subjective comfort. If a system "feels" nicer to use then I'll feel more motivated while using it which means I'll use it more and be more productive, and that's a sufficiently good reason to prefer one over the other. For me, that means using the keyboard and not the mouse.
There's a ton of comments here saying the keyboard is more ergonomic than the mouse, I've never heard that before and it feels wrong on its face (it's called repetitive strain injury, using multiple forms of input should helpful).
But generally, please if you believe this provide some kind of source.
It's one of the oldest forms of "programmer identity" out there, one of those shibboleths that people who culturally identify as a hacker express that's independent of its factuality. A bit of a precursor to social media which elevates in group shibboleths over data as a matter of course. Programmers were the first to invent and use social media after all.
It is more than just that it uses lisp. I do like that, and I think it is the correct choice. But it is more that even something as basic "move cursor down" is not tied directly to a specific key. And the help system will literally take you to the source for any command, if you ask it to. (Takes some setup for this to work down to the c source, but it is there.)
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.
You can but that doesn't neccesarily mean you should.
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.
Right, but not all, which is what makes unplugging your mouse from Windows painful. On Linux, I often forget to plug my mouse in and only notice when I want to play a game or something.
Emacs is great for people who are fine tinkering with their tools, and adjusting them to their needs and tastes. Emacs improves my quality of life quite a bit.
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.
> A lot of people hate that, they want a tool that has all relevant to their tasks front and center [...]
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.
I'm not talking about hyper-flexible tools like Emacs or Perl. I mean tools that do one thing, and do it well, with zero tweaking needed, or even allowed. A hammer, a hacksaw, a copy machine, a vending machine, software like age, or like notepad.exe. They can be learned end to end in a rather short time, and if you pick a hacksaw in a different workshop, it's almost guaranteed to work exactly the same as yours.
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.
> they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent
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.
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.
Some people want to just "do work" and not build a toolchest over the years. I think if I find myself doing something once, I will probably be doing it again, therefore the environment can help me greatly with achieving that goal in far less time. There is a diminishing return for some tasks, but some things I have written in emacs save me minutes of time each time they are run daily.
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.
I fit into this category so I might be able to explain. I'd like to learn emacs and build my perfect config for my WM and so on, but on top of that theres a long list of other stuff I want to do and build and learn. My time is finite and with all the other demands of life, my energy even moreso, so naturally I have to make sacrifices.
That doesn't sound like you "hate that", more like you're making a time management choice. I'd challenge it, as I find time spent on creating a good developmemnt environment pays off very well in overall productivity terms, up to a point, but it's your choice to make. Emacs certainly isnt for everyone, even among those that enjoy tinkering.
Life is full of decision points. It is very understandable to use your decision budget on things that matter, like your projects or your job or your money, than things that don't like an editor config. Over my decades of emacs use I've had periods of crazy tinkering and conversely years of doing nothing.
Completely agree. At the same time, I'd wager a good chunk of developers isn't really in it for a love of computers and tinkering. Not a bad thing per se, just my observation.
Emacs took a wrong fork in its own metaphor. At length, being able to take code and libraries between production and the editor would be a game changer. While Elisp has design features that make sense, in the tradeoffs, I think it lost to every other lisp with a general purpose programming ecosystem.
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 actually discovered that emacs is great as it is out of the box (except for creating annoying backup files with ~ at the end). I use it instead of nano and vim.
The more I learn about emacs the more I'm happy I never joined the cult
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
Emacs don’t have plugins. Emacs only have a small C core (kernel) that handles very low level details. Everything else is lisp code split into packages (libraries and utilities). And being a lisp means you can alter and redefine any symbol you want.
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.
There are a lot of caveats but in general the "spend 2 days" thing is a lot less true now IMHO thanks to LLM's that can write mostly correct elisp from basic specifications. YMMV of course. I have found this can also open up to being a lot more than "maybe 5% more efficient" for niche applications. It's the closest environment I've used to where the friction between "I wish my editor could do <x>" and actually having the feature almost disappears.
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.
My petty opinion is that distributions which disable the menu bar are bad, distributions which use an edgelord dark theme are bad, and distributions which do both are terrible. Where Doom in particular is concerned I dislike the fact that it starts with Vi keybindings by default (I quite disfavour modal editing, there's a reason I switched away from Vim after 5 years) and that it changes the 's' binding so I can't even rely on my muscle memory.
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.
I think some of these are unfair criticisms, because they are things that can be trivially changed. E.g. disabling evil mode or changing the theme are one-line modifications in the Doom config. After all, any opinionated Emacs distro has to make some choices otherwise there would be little point in anyone using one.
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.
One tip I read somewhere (possibly from Steve Yegge?) was that it's a good idea to disable the Emacs menu bar - and I agree. The Emacs menu bar is this kind of weird uncanny valley thing. It looks like a normal menu bar, but any time you click one of the items on it, you'll find that you're doing something that actually only makes sense if you're into Emacs already. It won't help you when you're starting out, and once you're up and running you won't need it (but you can ctrl+right click on the buffer to get if you ever feel like you do...) - and, meanwhile, it's taking up space on the screen that you could use for more lines of text.
(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.
The Edit menu has undo, cut, copy, and paste. Is that stuff that only makes sense if you're into Emacs already? The Help menu has the tutorial and the manual. Same question. The File menu has open file, save, save as, close, and quit. If you open a file which uses a mode which has options you get a menu showing those options.
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.
Hmm, good question. I had another go, for the first time in years, albeit with experienced Emacs eyes now, so I know roughly what's going on. Still felt like every click just gave me More Emacs Shit, which I remember being the main confusing thing.
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.)
> What's your take on opinionated distros like Doom Emacs or Spacemacs?
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
Whatever works for you works. If you want to use your editor for a goal, using the guardrails of Doom is fine. I use a vanilla setup as my base but I've been using emacs since before distributions. If you want to tinker or otherwise learn emacs more deeply, feel free to start from a vanilla config.
Don't use them. A personal config is highly personal, and a distro force someone else's preferences onto you. Even things like how exactly your config is organized.
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 went from Emacs to Vim to Vscode and back to Emacs with Doom, but I still use pretty much all of them. Vscode has copilot, Emacs has org mode, vim is great for light editing.
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 personally use Doom because there are a lot of out of the box optimizations, some don't like how hlissner has brought nix ideas of declarative package management into the mix, but I am a nix user so it makes sense. I also am an evil (heretic) user - Doom is configured from the get go as a gateway from vim/neovim into emacs, and it does that job very well.
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.
They have their place. I started out with Doom and it definitely helped to streamline the beginner phase where vanilla would have felt overwhelming. But, as with you, I soon became frustrated when I wanted to move beyond its default configuration.
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.
I have tried Doom Emacs in a Debian VM on Windows host, because that was the opportunity to install a new Emacs thing for me (to code while playing a game). There Doom Emacs was not stable. Sometimes it just crashed and one time I even lost a whole function I wrote, because somehow it doesn't do the same backup file thing Emacs usually does. The keybindings were nice, but the stability requirement I have overrules it. So I am back to standard Emacs and currently using evil mode.
I'm in the same boat and curious if other more experienced users have any resources to point to. My anedoctal data point is that after starting with doom emacs and having problems to set it up on another machine i fund out all i needed was a very small configuration file to accomplish my orgmode/agenda usage needs. So all it took was an issue and a clear vision of the goal to find a way through. Maybe it is a healthy approach to keep the complexity manageable to your usage
IMO, they're a great way to get started without having to invest too much time up-front. On the other hand, that was 10 years ago and it's a LOT easier to throw together a usable config nowadays; with LSP + built-in tree-sitter modes, you no longer need 3 packages per language plus a bunch of configuration glue.
>>I've been doing my daily journaling and task management on Emacs for while now
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.
> 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.
I live in EXWM. I absolutely love it as a coding environment. EXWM + helm + projectile. I mainly use v-term for cli, but I have always been interested in learning eshell, just never got around to it. I have been thread-locked on occasion, and when that happens it is frustrating. I can sometimes manage to switch to another session to kill processes and avoid restart, but not always. Still, I wouldn't leave EXWM. 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.
If you want to try eshell, try combining it with EAT (eat-eshell-mode).
> 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.
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.
I absolutely love Emacs, but I can't understand why people want it to be their window manager, of all things. Emacs can be many things, but high performance it is not. And WMs definitely are a high performance area.
They’re really not. Stability matters, but a wm has very little to do with actual rendering, it’s more placement, title bar and decorations, emacs as slow as it can be would be perfectly fine unless you have some crazy extensions on top, hence running two instances.
I do have a wandering eye for EXWM, it probably would require my skill with emacs to increase and an optimization of my config so as to defer heavy tasks etc. If you have any suggestions on how to get there, I am all ears! The more I use emacs, the more I want to make my entire computer emacs.
You likely don't need to optimize anything; Emacs has seen some pretty significant optimizations recently (native Emacs Lisp compilation, tree-sitter modes, better handling of long lines, etc.) so performance is rarely the issue.
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).
> This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
> 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.
A good carpenter takes time to maintain and procure their tools. They still have a nice phone and might listen to music on their headphones while they’re working. A chef must keep their kitchen clean and well organised. Stocked with appropriate and some obscure tools. She must season her saucepan, sharpen her knives.
My first career was as a cook and I would always sit and sharpen my knives after the last service of the week. It was kind of a cool time to reflect on the previous cycle and mentally prepare for the next. There's really nothing comparable in programming and I say this as someone who has spent hundreds of hours yak shaving emacs.
We do various tasks with computers. And it's not always in a linear fashion. What's important is reducing friction. The latter can manifest in various way, like having to battle with a GUI just to play some music, yet another GUI for email, and another one for your feeds. Emacs stuff can be pretty stable and you have the same interface for everything.
The bit about enabling org capture from "outside" Emacs is really interesting. It's been so important for me to have a system that enables me to make notes, todos etc. with extremely low friction. At any time, without my hands leaving the keyboard, I can take a note that is either directly attached to what I'm currently working on, arbitrarily file it somewhere if I know where it should go, or just let it go into the general inbox (the other part of the system is actually getting to those things in the inbox at some point). Up until this point I have had to be "in" Emacs, though, which accounts for most of my time, but not all.
I keep hearing about emacs and how awesome it is, is there a good resource for a complete beginner who is familiar with programming but not necessarily editors like vim or emacs, just to get started?
A good way to get straight in, is to download `emacs`, open it, and follow the built in "Emacs Tutorial" (click the link on the first page that is shown). It brings a new user through the concepts of the editor, how to move around, do some of the most usual actions, and get familiar with its vocabulary.
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.
Also be sure to use "C-h k" (describe-key), "C-h f" (describe-function) and "C-h v" (describe-variable) liberally. Emacs' self-documenting nature makes it significantly easier to understand what certain actions do and how certain options work.
> `magit` and `org-mode` are now part of the default installation)
I strongly recommend the book "Mastering Emacs" by Mickey P. You will need some patience as well, I recommend going slow and steady for a week at least using the book, with a vanilla/standard Emacs install.
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).
If you feel overwhelmed in trying out Emacs, always remember, you don't have to switch cold-turkey. You can keep working with your previous editor and use Emacs in your spare time. Or go 50-50. Or any other method that keeps the initial time of not being quite as productive from being a significant downside. Once you get the hang of it, you can still try it out for work and recognize small issues in the workflow, which you can then try to find fixes for in your spare time or spare time projects.
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.
I currently use nano for a lot of my plain text or markdown editing inside my terminal, and VSCode or Visual Studio for a lot of my IDE needs. I just keep hearing good things about how emacs can be a useful and cohesive system so I'm interesting in giving it a try haha
The book “Mastering Emacs” is nice. But both programs have tutorials builtin and extensive documentation. There’s also various youtube walkthrough videos for features.
Does anyone have a recommendation for a learning resource that approaches emacs as a computing environment in general, rather than as a text editor specifically? I think I may have had a lot of false starts learning emacs because I've been thinking of it too much like a replacement for vim, rather than a scriptable environment.
I’m exploring a similar implementation and am honestly torn between NixOS and a more monolithic experience like Debian or OpenBSD.
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.
I've greatly benefited from investing just a few hours then utilizing LLMs. I was very unfamiliar to a lot of the syntax from the nix language, so I spent most of my time getting an overview. It was less than 8 hours total.
Another thing that helps a lot is to browse other people's codes on Github.
OT: long time Emacs user, but my new employer insists on everyone using PhpStorm. And don't get me wrong, that's really a great IDE. I still miss Emacs, though.
I like eMacs but I feel the whole workflow is wrong. Buffers are a stacked tiled window manager inside your window manager. Your browser is a tabbed window manager, and many other applications are also window managers. I wish any sub buffer of any application was for all intents and purposes a dedicated window, so the WM can take care of the rest. Maybe it’s an adjustment that I could make in my workflow, but a global solution would have been nice. Too late now I guess though.
Exactly. I share the view that it doesn't make sense to effectively have two window managers running (one in my WM and one in Emacs) with different philosophies and shortcuts. But, and in a more general sense this is the great thing about Emacs, if you don't like its default behaviour you just change it.
I've used the no-tabs extension also for firefox when I used sway to integrate firefox into the WM. You can modify the userchrome to hide the tab bar completely. It worked really nicely, and should also work with exwm.
My "main" org file is 21k lines, it's no problem at all. My laptop is from 2017 or something.
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.
I finally made the switch to vim when I was working on a really large frontend template that consisted of the same massive repeated block where a small portion of each was different based on a condition.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
Not these days. Native Compilation made emacs a faster and there have been a lot of other changes. In fundamental-mode, emacs can handle really large files. When opening files literally, it's even faster. I have this 104k line org-mode file and it's reasonably responsive. Reverting it takes a while, but the UI does not hang while the buffer is being formatted according to the mode.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
In general, no... but also maybe yes. It's usually fine, but you may get extra unlucky in specific situations with specific major modes.
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.
No, but that’s not really relevant, my point is more that all buffers should be windows across all applications.
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.
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.
emacs, great if you dont mind coding it all yourself, in which case you could have coded an application directly for what you need, instead of it being a plugin to a text editor. but I guess its cool to use, so theres that intangible piece of nubbins to hold onto at least
This may sound strange, but I actually think we need just ... one editor.
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 1. The most perfect editor with all the features is created. We've done it. Everyone can tailor it perfectly to their workflow.
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.
Bluefish has had a release in October 2025 and the development page talks about gtk-3. Are you sure you've kept up to date with it? If you like it, stick with it.
> I have seen what people are capable of doing when their tools get out of the way, and they are free to just create. This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
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.
I'd go further. Some of the world's best tooling is only usable by the world's best users. Examples abound on this. The best drivers are in vehicles that I would almost certainly crash. Our best pilots are in planes that I literally don't understand the controls on. (That is true for the cars, too, oddly.)
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.
As you get better at something you become more opinionated at what you need your tools to do. You demand more specific and tailored things from your tools and so you start to lean towards things that are more adjustable.
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.
You made me think of this quote: "If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." - Antoine de Saint-Exupéry
"if you want to build 100 ships, refer to the former"
> 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.
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.
I think of it a bit differently: if the tool is getting in the way, this will hamper the effectiveness and raise the barrier for skilled individuals to do their best. Yeah, the absolute top-tier max-talent people can do well regardless, but if the tools are better quality and more "out of the way", this allows a greater pool of people to do their absolute best, with less friction.
> if the tools are better quality and more "out of the way", this allows a greater pool of people to do their absolute best, with less friction.
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.
It’s a poor carpenter who blames his tools
Russian equivalent of this idiom sounds like "skillful surgeon helps a bad dancer". Even though it sounds confusing, what it really means is "a bad dancer blames his balls"
It’s a poorer carpenter who uses a can of beans as a hammer. Pros are responsible for choosing appropriate tools.
Right, I get that. That's their opinion, and I was expressing a differing opinion (that's why I said "I think of it a bit differently" lol)
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/...
> Right, I get that. That's their opinion, and I was expressing a differing opinion (that's why I said "I think of it a bit differently" lol)
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.
Maybe it's a fallacy and maybe it isn't. But I often hear people say "I don't use tool X because it doesn't actually increase my productivity". X is emacs or debuggers or profilers or Linux or version control or code comments or whatever. And after observing such people work over time I decided that most of them are just trying to justify their laziness. YMMV.
Emacs is in a different category from all of those, since it gives the dev more control rather than more abstraction.
I think I agree that best tooling is not a sufficient condition for success.
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.
"Give me six hours to chop down a tree and I will spend the first four sharpening the ax."
"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."
Indeed. When you have superior skill, inferior tooling can be a constraint. But a superior tool will not compensate for inferior skill.
Agreed. You can have all the best tools and you still aren't guaranteed "success"
I think this is a bit of an oversimplification, I see art and technology as more like a dance where it's unclear who's leading who.
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?
Seems particularly funny in an article about Emacs, a piece of software that lets you get in situations where some portion of your "just create" time becomes "managing my custom emacs, please don't break".
One way to look it is to approach it as a creative practice. A good part of any practice is devoted to developing technique.
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.
I love Emacs. My first intro to it was on the Braille Plus Mobile Manager back in like 2008 or so. That was a beautiful device that ran Linux and was developed for the blind. There's been nothing exactly like it since. The BT Speak is a poor ematation that runs on a Raspberry Pi 4 and is sluggish because Linux accessibility is hard and not optomized for such low-power devices.
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.
Amazing.
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?
I am amazed by you, and humbled too. Thanks for sharing your experience!
This is a very good feature/workflow based intro
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
I used emacs(1) for a while as a development tool. When I went back to system administration, and before and after using emacs(1), I used vi(1).
I used it between 1995 and 2006 as replacement for not having proper IDEs on the UNIX systems I had to work on.
With that requirement going away, I left Emacs behind.
I’m perfectly happy woth IDEs for some projects, especially at work. But I tinker with enough ecosystems and OS and sometimes you just don’t have any IDEs. On almost all systems, I can copy my init.el and have my tools replicated in a few minutes.
The most seamless capture-from-anywhere workflow I struck upon is to have a shortcut on my phone's home screen. When tapped, it takes my dictation, transcribes it, and saves it to an inbox.org file with an org-syntax timestamp, synced to my main computer.
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’ve relied heavily on seamless capture for a couple of decades, ala Getting Things Done.
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'd be very curious to know more about the shortcut you describe. This workflow would work incredibly well for me. I already have my notes synced via syncthing, and capture with Orgzly Revived, but auto-transcribed captures would be a gamechanger.
It’s an iphone shortcut. Here it is: https://www.icloud.com/shortcuts/a8a0076cc03f4e699d8ca34bd3d...
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?
Awesome - are you on an Android?
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.
This isn't rsync, but you can integrate a-Shell[0] with iOS Shortcuts. You would need to make the syncing happen in the script instead of in the background though. I use a Python script to create aliases for my email this way, so I don't have to turn on wildcard addressing to my inbox.
[0] https://github.com/holzschu/a-shell
Iphone, yes. I keep the file on dropbox so that is what keeps it synced.
Shortcut: https://www.icloud.com/shortcuts/a8a0076cc03f4e699d8ca34bd3d...
[dead]
The more I learn about emacs the more I feel we took the wrong fork on road in terms of the desktop metaphor decades ago.
For me, the power of Emacs is mainly that I can do everything with the keyboard, which is not only much faster, but also - to me - much more enjoyable than going through visual menus with the mouse.
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.
When I got into emacs 20+ years ago the "use only the keyboard" thing was a huge point of pride and to this day I don't understand why. Who cares? I use emacs because I can code the entire environment.
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.
Use what works for you.
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).
this blog post?
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.
> 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.
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.
> 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
> 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).
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.
There’s the acme editor for a truly nice usage of the mouse. Even emacs make a better usage of the mouse than most editors.
> Who cares?
People with RSI from constantly reaching for a mouse.
I have been coding for so long now that I can't have my keyboard any higher than my lap. I code with it resting directly on my legs. A mouse is right out. Any higher, and my hands turn to clubs.
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.
Ah, like my eMacs pinky and thumb? ;)
I literally went to an orthopedic specialist recently for overuse of the left alt key causing me pretty notable pain in my thumb.
Alternate between using the left and right Alt keys. The ergonomist's rule of thumb (no pun intended) is to use both halves of the keyboard. So if pressing Alt-x, use the right Alt button, etc.
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."
Yes, I’m also on a Mac (for now), and I do make fairly minimal use of my mouse. My problem is defeating years of muscle memory
As the sibling comment put it, that’s when I look into ergonomics accessories.
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.
An ergonomic keyboard can help. I like the Kinesis Advantage but it's expensive for a keyboard.
Ah yes, stop Repetitive Stress Injury by reducing variation and increasing repetitive motions.
This is the thing people forget about emacs - it is primarily a lisp environment, entirely programmable. Something one can make their very own. Nothing else comes quite as close, even if the keyboard ergonomics (at least for me) do help to sell it. You can change the workspace to better the workflow in real time, that's the biggest selling feature.
And this is why, even though it is a better OS environment my grandmother will never use it.
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.
I'm not going to argue that emacs if "for everyone" and there's plenty in my own life that I'm happy to accept defaults in. But that said, it's not that hard to glue emacs onto existing tools if needed. If you're in a situation where you can only send emails on a locked down email client you can still script the client through emacs and some glue code. On MacOS, Apple script does wonders and for Windows there's AutoHotKey. Linux obviously is infinitely malleable.
To be fair to corporate, Emacs has a pretty terrible security model.
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.
I think this largely misses the point. It isn't about which out of keyboard vs mouse is objectively better or faster. It's about subjective comfort. If a system "feels" nicer to use then I'll feel more motivated while using it which means I'll use it more and be more productive, and that's a sufficiently good reason to prefer one over the other. For me, that means using the keyboard and not the mouse.
There's a ton of comments here saying the keyboard is more ergonomic than the mouse, I've never heard that before and it feels wrong on its face (it's called repetitive strain injury, using multiple forms of input should helpful).
But generally, please if you believe this provide some kind of source.
It's one of the oldest forms of "programmer identity" out there, one of those shibboleths that people who culturally identify as a hacker express that's independent of its factuality. A bit of a precursor to social media which elevates in group shibboleths over data as a matter of course. Programmers were the first to invent and use social media after all.
Using the mouse too much gives you RSI syndrome. Frankly, using Vim (or neovim nowadays) over Emacs is even better for preventing that...
You can do everything with mouse (or touchscreen). Lets start with these:
> The next best thing I love about Emacs is that I can do anything conceivable with code.
you already could though, no? emacs didnt allow you to execute lisp for the first time
It is more than just that it uses lisp. I do like that, and I think it is the correct choice. But it is more that even something as basic "move cursor down" is not tied directly to a specific key. And the help system will literally take you to the source for any command, if you ask it to. (Takes some setup for this to work down to the c source, but it is there.)
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.
Believe or not, you can go 100% keyboard-only even on Windows. I had a friend, Win server admin (big Microsoft fun), who wasn't using mouse at all.
You can but that doesn't neccesarily mean you should.
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.
Which is why most programs support alt-hotkeys.
Right, but not all, which is what makes unplugging your mouse from Windows painful. On Linux, I often forget to plug my mouse in and only notice when I want to play a game or something.
Emacs is great for people who are fine tinkering with their tools, and adjusting them to their needs and tastes. Emacs improves my quality of life quite a bit.
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.
> A lot of people hate that, they want a tool that has all relevant to their tasks front and center [...]
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.
I'm not talking about hyper-flexible tools like Emacs or Perl. I mean tools that do one thing, and do it well, with zero tweaking needed, or even allowed. A hammer, a hacksaw, a copy machine, a vending machine, software like age, or like notepad.exe. They can be learned end to end in a rather short time, and if you pick a hacksaw in a different workshop, it's almost guaranteed to work exactly the same as yours.
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.
> a vending machine
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.
> they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent
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.
Polite tools that assume competence are such a pleasure to use.
> [...] people hate that [...]
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.
Some people want to just "do work" and not build a toolchest over the years. I think if I find myself doing something once, I will probably be doing it again, therefore the environment can help me greatly with achieving that goal in far less time. There is a diminishing return for some tasks, but some things I have written in emacs save me minutes of time each time they are run daily.
> A lot of people hate that
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.
I fit into this category so I might be able to explain. I'd like to learn emacs and build my perfect config for my WM and so on, but on top of that theres a long list of other stuff I want to do and build and learn. My time is finite and with all the other demands of life, my energy even moreso, so naturally I have to make sacrifices.
That doesn't sound like you "hate that", more like you're making a time management choice. I'd challenge it, as I find time spent on creating a good developmemnt environment pays off very well in overall productivity terms, up to a point, but it's your choice to make. Emacs certainly isnt for everyone, even among those that enjoy tinkering.
Life is full of decision points. It is very understandable to use your decision budget on things that matter, like your projects or your job or your money, than things that don't like an editor config. Over my decades of emacs use I've had periods of crazy tinkering and conversely years of doing nothing.
Completely agree. At the same time, I'd wager a good chunk of developers isn't really in it for a love of computers and tinkering. Not a bad thing per se, just my observation.
Emacs took a wrong fork in its own metaphor. At length, being able to take code and libraries between production and the editor would be a game changer. While Elisp has design features that make sense, in the tradeoffs, I think it lost to every other lisp with a general purpose programming ecosystem.
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 entirely agree - we could have had a completely unified computing environment, and we got... apps.
I actually discovered that emacs is great as it is out of the box (except for creating annoying backup files with ~ at the end). I use it instead of nano and vim.
Emacs is 100% nearly perfect, the only thing holding back emacs is emacs.
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.
Stallman was right.
The more I learn about emacs the more I'm happy I never joined the cult
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
Emacs don’t have plugins. Emacs only have a small C core (kernel) that handles very low level details. Everything else is lisp code split into packages (libraries and utilities). And being a lisp means you can alter and redefine any symbol you want.
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.
> 5% less efficient
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.
There are a lot of caveats but in general the "spend 2 days" thing is a lot less true now IMHO thanks to LLM's that can write mostly correct elisp from basic specifications. YMMV of course. I have found this can also open up to being a lot more than "maybe 5% more efficient" for niche applications. It's the closest environment I've used to where the friction between "I wish my editor could do <x>" and actually having the feature almost disappears.
A question for the heavy Emacs users:
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.
My petty opinion is that distributions which disable the menu bar are bad, distributions which use an edgelord dark theme are bad, and distributions which do both are terrible. Where Doom in particular is concerned I dislike the fact that it starts with Vi keybindings by default (I quite disfavour modal editing, there's a reason I switched away from Vim after 5 years) and that it changes the 's' binding so I can't even rely on my muscle memory.
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.
I think some of these are unfair criticisms, because they are things that can be trivially changed. E.g. disabling evil mode or changing the theme are one-line modifications in the Doom config. After all, any opinionated Emacs distro has to make some choices otherwise there would be little point in anyone using one.
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.
One tip I read somewhere (possibly from Steve Yegge?) was that it's a good idea to disable the Emacs menu bar - and I agree. The Emacs menu bar is this kind of weird uncanny valley thing. It looks like a normal menu bar, but any time you click one of the items on it, you'll find that you're doing something that actually only makes sense if you're into Emacs already. It won't help you when you're starting out, and once you're up and running you won't need it (but you can ctrl+right click on the buffer to get if you ever feel like you do...) - and, meanwhile, it's taking up space on the screen that you could use for more lines of text.
(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.
The Edit menu has undo, cut, copy, and paste. Is that stuff that only makes sense if you're into Emacs already? The Help menu has the tutorial and the manual. Same question. The File menu has open file, save, save as, close, and quit. If you open a file which uses a mode which has options you get a menu showing those options.
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.
Hmm, good question. I had another go, for the first time in years, albeit with experienced Emacs eyes now, so I know roughly what's going on. Still felt like every click just gave me More Emacs Shit, which I remember being the main confusing thing.
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.)
> What's your take on opinionated distros like Doom Emacs or Spacemacs?
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
Whatever works for you works. If you want to use your editor for a goal, using the guardrails of Doom is fine. I use a vanilla setup as my base but I've been using emacs since before distributions. If you want to tinker or otherwise learn emacs more deeply, feel free to start from a vanilla config.
Don't use them. A personal config is highly personal, and a distro force someone else's preferences onto you. Even things like how exactly your config is organized.
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 went from Emacs to Vim to Vscode and back to Emacs with Doom, but I still use pretty much all of them. Vscode has copilot, Emacs has org mode, vim is great for light editing.
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 personally use Doom because there are a lot of out of the box optimizations, some don't like how hlissner has brought nix ideas of declarative package management into the mix, but I am a nix user so it makes sense. I also am an evil (heretic) user - Doom is configured from the get go as a gateway from vim/neovim into emacs, and it does that job very well.
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.
They have their place. I started out with Doom and it definitely helped to streamline the beginner phase where vanilla would have felt overwhelming. But, as with you, I soon became frustrated when I wanted to move beyond its default configuration.
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.
I have tried Doom Emacs in a Debian VM on Windows host, because that was the opportunity to install a new Emacs thing for me (to code while playing a game). There Doom Emacs was not stable. Sometimes it just crashed and one time I even lost a whole function I wrote, because somehow it doesn't do the same backup file thing Emacs usually does. The keybindings were nice, but the stability requirement I have overrules it. So I am back to standard Emacs and currently using evil mode.
[dead]
I'm in the same boat and curious if other more experienced users have any resources to point to. My anedoctal data point is that after starting with doom emacs and having problems to set it up on another machine i fund out all i needed was a very small configuration file to accomplish my orgmode/agenda usage needs. So all it took was an issue and a clear vision of the goal to find a way through. Maybe it is a healthy approach to keep the complexity manageable to your usage
IMO, they're a great way to get started without having to invest too much time up-front. On the other hand, that was 10 years ago and it's a LOT easier to throw together a usable config nowadays; with LSP + built-in tree-sitter modes, you no longer need 3 packages per language plus a bunch of configuration glue.
>>I've been doing my daily journaling and task management on Emacs for while now
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.
Re EXWM and:
> 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.
I live in EXWM. I absolutely love it as a coding environment. EXWM + helm + projectile. I mainly use v-term for cli, but I have always been interested in learning eshell, just never got around to it. I have been thread-locked on occasion, and when that happens it is frustrating. I can sometimes manage to switch to another session to kill processes and avoid restart, but not always. Still, I wouldn't leave EXWM. 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.
If you want to try eshell, try combining it with EAT (eat-eshell-mode).
> 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.
Thank you stebalien, I will remember these points about EXWM / emacs and concurrency. I'll look into EAT as well.
I don’t imagine I’d want to use my general emacs as my window manager, I imagine the sanest way would be to run two instances of emacs.
I absolutely love Emacs, but I can't understand why people want it to be their window manager, of all things. Emacs can be many things, but high performance it is not. And WMs definitely are a high performance area.
They’re really not. Stability matters, but a wm has very little to do with actual rendering, it’s more placement, title bar and decorations, emacs as slow as it can be would be perfectly fine unless you have some crazy extensions on top, hence running two instances.
Fair. Regardless, it just seems like an odd tool for the job.
I do have a wandering eye for EXWM, it probably would require my skill with emacs to increase and an optimization of my config so as to defer heavy tasks etc. If you have any suggestions on how to get there, I am all ears! The more I use emacs, the more I want to make my entire computer emacs.
You likely don't need to optimize anything; Emacs has seen some pretty significant optimizations recently (native Emacs Lisp compilation, tree-sitter modes, better handling of long lines, etc.) so performance is rarely the issue.
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).
> This is how world class athletes, musicians, artists, writers, and of course programmers take what is in their mind and translate it into reality.
> 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.
A good carpenter takes time to maintain and procure their tools. They still have a nice phone and might listen to music on their headphones while they’re working. A chef must keep their kitchen clean and well organised. Stocked with appropriate and some obscure tools. She must season her saucepan, sharpen her knives.
My first career was as a cook and I would always sit and sharpen my knives after the last service of the week. It was kind of a cool time to reflect on the previous cycle and mentally prepare for the next. There's really nothing comparable in programming and I say this as someone who has spent hundreds of hours yak shaving emacs.
In programming anything you do (eg yak shaving) takes up your whole mind.
Sharpening knives leaves mental space for reflection.
> I would always sit and sharpen my knives
Tech debt
We do various tasks with computers. And it's not always in a linear fashion. What's important is reducing friction. The latter can manifest in various way, like having to battle with a GUI just to play some music, yet another GUI for email, and another one for your feeds. Emacs stuff can be pretty stable and you have the same interface for everything.
The bit about enabling org capture from "outside" Emacs is really interesting. It's been so important for me to have a system that enables me to make notes, todos etc. with extremely low friction. At any time, without my hands leaving the keyboard, I can take a note that is either directly attached to what I'm currently working on, arbitrarily file it somewhere if I know where it should go, or just let it go into the general inbox (the other part of the system is actually getting to those things in the inbox at some point). Up until this point I have had to be "in" Emacs, though, which accounts for most of my time, but not all.
I keep hearing about emacs and how awesome it is, is there a good resource for a complete beginner who is familiar with programming but not necessarily editors like vim or emacs, just to get started?
A good way to get straight in, is to download `emacs`, open it, and follow the built in "Emacs Tutorial" (click the link on the first page that is shown). It brings a new user through the concepts of the editor, how to move around, do some of the most usual actions, and get familiar with its vocabulary.
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.
Also be sure to use "C-h k" (describe-key), "C-h f" (describe-function) and "C-h v" (describe-variable) liberally. Emacs' self-documenting nature makes it significantly easier to understand what certain actions do and how certain options work.
> `magit` and `org-mode` are now part of the default installation)
Org is, but magit is not.
The "Mastering Emacs" is great. But, you don't need it to get started, instead check https://www.masteringemacs.org/reading-guide
I strongly recommend the book "Mastering Emacs" by Mickey P. You will need some patience as well, I recommend going slow and steady for a week at least using the book, with a vanilla/standard Emacs install.
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).
If you feel overwhelmed in trying out Emacs, always remember, you don't have to switch cold-turkey. You can keep working with your previous editor and use Emacs in your spare time. Or go 50-50. Or any other method that keeps the initial time of not being quite as productive from being a significant downside. Once you get the hang of it, you can still try it out for work and recognize small issues in the workflow, which you can then try to find fixes for in your spare time or spare time projects.
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.
I currently use nano for a lot of my plain text or markdown editing inside my terminal, and VSCode or Visual Studio for a lot of my IDE needs. I just keep hearing good things about how emacs can be a useful and cohesive system so I'm interesting in giving it a try haha
i would heartily recommend micky-petersen's : Mastering Emacs (https://www.masteringemacs.org/about)
The book “Mastering Emacs” is nice. But both programs have tutorials builtin and extensive documentation. There’s also various youtube walkthrough videos for features.
https://www2.lib.uchicago.edu/keith/emacs/
There's a wiki page with links to plenty of resources: https://www.emacswiki.org/emacs/SiteMap
Does anyone have a recommendation for a learning resource that approaches emacs as a computing environment in general, rather than as a text editor specifically? I think I may have had a lot of false starts learning emacs because I've been thinking of it too much like a replacement for vim, rather than a scriptable environment.
I’m exploring a similar implementation and am honestly torn between NixOS and a more monolithic experience like Debian or OpenBSD.
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.
I've greatly benefited from investing just a few hours then utilizing LLMs. I was very unfamiliar to a lot of the syntax from the nix language, so I spent most of my time getting an overview. It was less than 8 hours total. Another thing that helps a lot is to browse other people's codes on Github.
Re: author's comments about exwm
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.
OT: long time Emacs user, but my new employer insists on everyone using PhpStorm. And don't get me wrong, that's really a great IDE. I still miss Emacs, though.
Not one mention of SSH or remote development. Life must be nice to do development on a single machine. Tramp on Emacs is not ideal.
You start an emacs server on each machine you might use. Then ssh and emacsclient -nw. You need a decent terminal but life is simple.
I like eMacs but I feel the whole workflow is wrong. Buffers are a stacked tiled window manager inside your window manager. Your browser is a tabbed window manager, and many other applications are also window managers. I wish any sub buffer of any application was for all intents and purposes a dedicated window, so the WM can take care of the rest. Maybe it’s an adjustment that I could make in my workflow, but a global solution would have been nice. Too late now I guess though.
You can configure Emacs to open each buffer in a new frame — ie “window” and manage them with your window manager
Exactly. I share the view that it doesn't make sense to effectively have two window managers running (one in my WM and one in Emacs) with different philosophies and shortcuts. But, and in a more general sense this is the great thing about Emacs, if you don't like its default behaviour you just change it.
EXWM + Qutebrowser can work like that. The individual tabs of Qutebrowser become Emacs buffers.
I've used the no-tabs extension also for firefox when I used sway to integrate firefox into the WM. You can modify the userchrome to hide the tab bar completely. It worked really nicely, and should also work with exwm.
Doesn’t emacs slow down on really long files? I mean like 8,000 lines
My "main" org file is 21k lines, it's no problem at all. My laptop is from 2017 or something.
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.
I finally made the switch to vim when I was working on a really large frontend template that consisted of the same massive repeated block where a small portion of each was different based on a condition.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
Not these days. Native Compilation made emacs a faster and there have been a lot of other changes. In fundamental-mode, emacs can handle really large files. When opening files literally, it's even faster. I have this 104k line org-mode file and it's reasonably responsive. Reverting it takes a while, but the UI does not hang while the buffer is being formatted according to the mode.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
I’ll bite, wtf is your org file?
It's three months of text I need to refile.
In general, no... but also maybe yes. It's usually fine, but you may get extra unlucky in specific situations with specific major modes.
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.
No, but that’s not really relevant, my point is more that all buffers should be windows across all applications.
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.
Are there any good videos showcasing a productive Emacs setup like this and how it's used for everyday tasks?
not exactly what you seek, but i like the emacs rocks clips: https://emacsrocks.com/
they're nice and short, but note that the latest one is 8 years old ;-)
(though https://www.youtube.com/@emacsrocks has newer stuff by the same person, seems like game dev in clojure and emacs)
https://systemcrafters.net/emacs-from-scratch/
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.
I think i finally pass this stage....not doing everything in Emacs..
emacs, great if you dont mind coding it all yourself, in which case you could have coded an application directly for what you need, instead of it being a plugin to a text editor. but I guess its cool to use, so theres that intangible piece of nubbins to hold onto at least
If the application you are writing is text based, Emacs is a great environment to write it in.
so why is he using nix then when there is emacs
This may sound strange, but I actually think we need just ... one editor.
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 1. The most perfect editor with all the features is created. We've done it. Everyone can tailor it perfectly to their workflow.
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.
Bluefish has had a release in October 2025 and the development page talks about gtk-3. Are you sure you've kept up to date with it? If you like it, stick with it.
Why would I use emacs instead of Helix editor for any language other than Lean or Agda?
Why would I use Helix editor instead of Emacs?