▲ 141 points
back
99 comments
Since Steve Purcell loves new technologies and update his setup
frequently, it may be a little harder to follow him for beginners.
That’s actually great. I’m lucky to stick to his setup because pulling
from his git branch gets me updated with the latest cool things in
community.
When I say “on the shoulders of giants”, I’m stressing that you need
set your standard higher. I’m NOT saying the master’s setup is “newbie
friendly”. If it happens to be “friendly”, it’s just the coincidence.
Also, cargo culting everybody to use the Evil mode for Vim bindings in Emacs is also probably bad advice, unless you are teaching emacs to a vim user.
As a beginner, you are better off starting your emacs config from scratch.
Some of the opinions of the author have been stated as facts:-
...every master uses the package smex to remember keybindings
Mickey walks you chapter by chapter, while you build your own emacs configuration as you learn new things.
Once you have worked through that textbook, you will find it a piece of cake to study other people's configurations on github and learn more.
If you are looking for motivation to learn emacs, watch the short 2 minute demo videos on the Youtube Channel @EmacsRocks
In my opinion, as of 2023, the best way to learn emacs the right way is through the textbook 'Mastering Emacs' by Mickey Petersen. Trust me, that book is well worth the price tag.
Strongly second this opinion!
Mickey Petersen simply has no equal in explaining Emacs. His book and blog posts are a model of effective teaching, starting from zero. Yet somehow gently ceomprehensive. Hard recommend.
Emacs from scratch is the way to go. Added abstractions are usually not good enough to completely replace fiddling around with vanilla Emacs.
Two videos by Steve Yegge should be enough to convince the most dyed-in-the-wool anti-Emacser to consider re-evaluating their position. (Here is the first: https://www.youtube.com/watch?v=lkIicfzPBys).
My top-tip, FWIW, is learning how to navigate the help system to the point that it drags you into the deepest layers of Emacs' source code.
> smex
The three packages, whichkey, helpful and marginalia are excellent for beginners for quick overviews of what's going on at the surface.
And, yes, Mickey P's work is undoubtedly of great value!
The Paul Nordstrom comment is so funny to me. I joined his team in (I think) late 2000 to build the distributed system that moved Amazon from the single (massive) monolithic binary. I was using vi at the time and I could see him physically cringe when he stood over my shoulders watching me move through code. It's like he was in pain.
He told me (a 23-year-old) to pick an editor and learn it well. He said vi was fine but he didn't know it well and couldn't really help me. But if I wanted to learn Emacs he would help me. So, he brought me up to speed. He sat behind me and helped me through the basics. He helped me set up a usable .emacs file. When we would sit at his desk he would tell me what he was doing with Emacs so I could see how a ninja would do things.
23 years later I still use Emacs and I am still learning new things.
It's people like Paul that really make a difference for junior engineers.
He got me about five years later. I had used emacs in college so it was a smoother transition. Still my only editor today. I have failed to pass emacs knowledge on to the next generation so far.
Becoming productive with Emacs should take you a couple of weeks. At least that's what it took my dumb 19 year old self back in the day. Mastering emacs? I don't think you should be expected to do such thing.
> At least that's what it took my dumb 19-year-old self back in the day
That's the one thing I miss about being a teen: few enough other options that I'd stick to things to mastery instead of giving up and reverting to the tools I already know once things hit my frustration threshold.
Back in my larval stage I adopted Emacs because it was considerably more “intuitive” than vi and wasn’t a joke like pine. I found it suitable for writing C and xpilots[1] configs out of the box and went from there. It did help that I was mostly in a college CS lab so there were people to ask questions.
The content here is that they’ve:
- Done the built-in tutorial;
- Picked up somebody else’s Emacs and a few packages.
That’s two hours, maybe, if you go slow and have a few beers in the meantime. I wonder what they did for the rest of the year.
I'm not sure I agree with the necessity of mastering Emacs, or specifying a time frame for getting it done as the title of the article implies. I've used Emacs alongside of vi for editing since the 1990s. I'm no expert at using Emacs, but that's never really mattered to me.
On the other hand Emacs is a key part of how I use computers. I read email, use the calendar, and edit text of all kinds. I use outline mode, and now Org mode to help organize and author text. I'm also a long time user of, and occasional author for info mode. I still tend to use vi for quick edits of line oriented text. For everything else I use Emacs.
I'll suggest new users simply use the built-in tutorial to get started with GNU Emacs, and learn the new features as time goes by, and your needs change.
Related:
Master Emacs in one year - https://news.ycombinator.com/item?id=16424934 - Feb 2018 (5 comments)
Master Emacs in one year - https://news.ycombinator.com/item?id=8079083 - July 2014 (116 comments)
The focus on leaning on “giants” and not being creative is a bit too much for my taste.
I kind of get it, but it feels off.
“Those giants are more intelligent than me. They are harder working than me. How can I reach their level as quickly as possible?”
Not by blindly copying everything I imagine, but I could be wrong.
"First, you copy the master. Then, you master the master"
Can't find the source of the quote but it was about the Chinese approach to learning.
Copying the setup of an emacs guru sounds like a great idea to me. Think of it as using a Linux distro instead of building your own Linux from scratch. What turned me off of emacs as my daily driver, after using it from college through the first ten years of my career, was the large number of packages that came highly recommended by the community but which were half-baked or required debugging and subtle adjustments to coexist with other packages.
When the author says:
> Don’t try to be “creative” at this stage.
What he means by that is that if you try to configure emacs yourself, without yet being a master, half of the functionality you try to use will be broken, and you'll spend countless hours reading code and figuring out how to fix your broken setup. This is the traditional way to master emacs: by going back and forth between writing your own modifications and struggling to incorporate other people's code. Tackle every challenge head-on, and solve them one by one to make emacs do what you need. The daily effort to do turns you into an emacs master, like turning the wheel of pain turned the boy Conan into a 1970s bodybuilder.
I don't think that's a wise or attractive route for new emacs users today. Nowadays, everything I could do in emacs I can do with other freely available software as well, and I have to ask myself whether it makes more sense to invest the time figuring out how to do it in emacs, or to install an easier and more polished special-purpose tool. When my workflow revolved entirely around emacs, it made sense to make the extra effort. But over time my workflow fragmented, until the extra effort never made sense, and my emacs setup stopped growing.
Copying the setup of somebody who has already invest the time to get everything working together sounds like a nice compromise.
I doubt it'd take a year. Just remember, `C-h` is your friend, and there's no shame in using Doom / Spacemacs. Even if you're a vim devotee you can switch full-time to linux, thanks to `evil`. Emacs has a much better GUI than vim / gvim and related.
Starting with vim keybinds, you can be very productive in just an afternoon, because `evil` is extremely comprehensive in mimicking vim. After that, you'd want to learn some elisp, and making small functions with the basic `let` and `interactive` forms will get you up to speed. A year is overkill. You can start being productive in emacs in less than a week.
Emacs it's bearable with persp-mode. If you set the global keybind to C-c C-w (as it was with
some former buffer manager) you'll find yourself using C-c -C-w b more than C-x b, because it will show you the isolated buffer per "pane" a la Screen/Tmux.
You can use the first pane for editing, the second one for eww, another one for programming, one more for M-x calc (and the GNU info help page) and so on. Much better than cluttering your buffer list.
C-c C-w s to create a new pane, and C-c C-w C to destroy it, and C-c C-w ? in order to get help. That's it.
I second „persp-mode.el“ to be a great early addition to your default setup. I usually do that to separate front end from backend code or source files from remote terminals and/or error logs.
Wherever I can I use default key bindings which actually helps me with remembering. In this case I stuck to „C-x x“ as a prefix key combo.
I would also suggest to first install „which-key.el“ which will make Emacs display a list of possible key bindings from where from the key combo you just typed. This way hitting „C-x x“ will give you a menu displaying all possible persp-mode actions and will become second nature.
I find that with project.el (or projectile) buffer handling per repo works fine without having to separate things into frames. I often have hundreds of buffers open after a while and finding the right one is rarely a problem.
I’ve been using vim for 3-4 years now, and I’m very comfortable in the vim ecosystem. Trying out emacs has been in my mind for a while, but I’m not sure if it’s worth the time investment.
I used (and use) vim for over a decade.
I've used emacs for probably over a year now.
I'm glad I learned modal editing with vim, but with doom emacs there is nothing I miss from vim, except maybe `ctrl-p`, `projectile` isn't as good in certain cases, but it's good enough.
In my opinion emacs is just better for everything, and if you know vim well enough doom will take 10 minutes to learn to use. Those 10 minutes are the install. Most vim commands will _just work_.
I‘ve also been using vim for ~3yrs now, editing small programming projects and all kinds of text in it (like config files). Never had a need for emacs until a couple weeks ago I started working at a project involving a lot of meetings and writing a TeX report. I experienced that emacs, used in the auctex and org modes, is helping me a lot with that because the available commands simplify the workflow (like `reftex-citation`).
Why has trying out emacs been on your mind, if I may ask? If it‘s just for fun, go ahead. If it‘s because you think aspects of your workflow could be optimized, take a look at the several modes emacs has to offer. Otherwise, I would just stay with vim, tbh.
Once you go Emacs, you never go back.
I moved to emacs (with its own keybindings) after using vim for a decade.
Learning something new and very different to what you are used to is always worth the time investment. It doesn't mean you have to necessarily leave vim.
Start with Doom Emacs, you get sensible defaults out of the box and familiar vim bindings, but with all the emacs goodness
You can just use it for note taking and as an outliner (orgmode) and keep using vim for programming.
Alternately, spend a weekend learning VS.Code and get on with doing real work.
(I spent 20+ years with emacs, including writing one of the first popular HTML modes in 1993. We have better tools now!)
"real work" "better tools"
Data point: I do real work in emacs (people pay me money for it). I haven't written any major emacs modes (use-package desired-feature) is it for me. I've looked at vs code (to get personal experience e.g., gitlens is nice though I mostly use magit plus several "feature" packages). Emacs is much better tool for me: I have an order of magnitude more notes than corresponding code (org-mode is life changing), say, 300 lines of notes per 30 lines of code.
I have many of my colleagues use vs code--expectedly, I don't see the "betterness." Ultimately, I don't care what tools do you use as long as the results are acceptable.
Though, I don't understand why someone would use less powerful tools long-term. Given your 20+ years experience, it is interesting to see some specific examples.
Often, I enjoy running emacs (and vim) in a terminal. (And, by the way, as we all know, “VSCode” stands for “Eight Gigabytes And Constantly Swapping.”)
More like 5 minutes. Install the extensions for your programming languages and frameworks of choice (who conveniently embed LSP), learn Cmd+Maj+P to get the global command palette, and start working.
That's funny. I actually come from VSCode. I grew so sick of it that I decided to try Emacs. I hadn't done it because I always saw it as a meme because I always heard jokes about it.
I was horrified for months. How did no one tell me how much better Emacs is over pretty much everything and especially VSCode?
In terms of brilliance, VSCode is a photon or two. Emacs is the Tarantula Nebula.
I use VSCode and Jupyter for writing code, but I always have emacs open for doing edits that would be time-consuming and onerous in VSCode, Jupyter, or my rich database client. I feel caught between the failure of text editors to become rich tools, and the failure of rich tools to become good text editors.
If you spent 20+ years with Emacs, you should probably know to not compare it with VS Code. Emacs is more comparable to Bash than IDEs.
There is something fundamentally wrong with a UI/UX that takes a literal year to master. I can’t think of a better argument against learning emacs than the title of this submission.
In reality, Emacs has the gentlest UI/UX of any Unix tool. Emacs has tutorials built-in, is 100 percent documented and all of the moving bits and pieces are discoverable.
Nonsense. Just like with any software you can be perfectly productive in an afternoon but actual mastery takes time. For instance, for Microsoft Excel the title would probably be "Master Excel in two years"
Would you please show me a tool with a better UI/UX that can do all the things that emacs can do?
Orgmode Magit Dired EXWM . . . this rabbit hole is an endless pursuit of higher and higher efficiency.
BTW, the UI/UX is quite customizable with basic elisp fu, using say Helm, Ivy etc.
It’s a productivity tool. It also takes months or years to master a professional video editing software like Adobe Premier, or 3D graphics software like Blender. People take time to learn because it’s worth it.
I would not imagine mastering VSCode or any Jetbrains suite product to take any less time.
I agree. But you should learn Emacs anyway, because mastering such a powerful tool, even if it takes a long time - and even if you don't really need it - is FUN!
I guess programming [1] isn’t worth learning, then?
Yeah, do they really think "learn in one year" is a compliment?
Interesting how they claim it's compatible with vim was an advantage, oh well but aren't you trying to get me away from it? Sure it's a "shorter learning curve" (if they somehow get rid of all the emacsism before getting to that mode and learn nobody has a "meta" key in their computer)
I could learn a lot of more fulfilling things than emacs in a year. Guess I'll just stick with vim and vscode
> There is something fundamentally wrong with a UI/UX that takes a literal year to master.
You can learn basic navigation in about 5 to 10 minutes reading through emac's built in tutorial. Mastering it means finding a configuration that works for you, or writing your own implementation.
I don't use emacs regularly (other than as an info page browser), but I have been using vim for the last 20 years and am still learning new things about it.
I have read plenty of anecdotes on HN about people choosing the wrong platform. In my opinion, Emacs displays characteristics of a wrong platform to invest time in.
I know that Emacs is a very powerful and completely open-source platform, but I have questions about its long-term viability. It's not commonly introduced in CS programs/bootcamps so it'll lead to a declining market share, and its most powerful capabilities require knowledge of LISP, which is not a popular language.
Time and energy spent learning Emacs is also non-transferable as it has a one-of-a kind shortcut/user interface. The student will be locked in to Emacs.
Students should invest time learning VSCode instead. At least it'll be easy to switch to other products.
One year is not bad to master a whole OS!
Waste of time. Better off to master JavaScript and extend VS Code / Codium / et. al.
At least the JS knowledge will carry over to something employable.
Well, that‘s a valid opinion and I am not telling anyone what tools to use.
But as a senior I have seen many colleagues moving from one IDE du jour to the next and spending many hours of reconfiguring their tools while I just stuck to using Emacs all these years with a moderate shift of packages. I’ve been programming C, C++, Perl, JavaScript (and its various ECMA incarnations), React components, SQL and even Lua. Nowadays I am doing my terminal sessions from Emacs, too, and enjoy Tramp mode for tracing live bugs. Also, I started writing SQL change sets using org-mode which is really a killer for me now. Emacs is such a versatile programming tool and does not stop amazing me.
VS Code looks so boring in comparison.
Also my colleagues keep on whining about the CPU and memory consumption of their IDE that is quite large for, well, ultimately, text editing.
Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Emacs is geared towards people that use it regularly, and its defaults hardly ever change.
I'm going to post it as a reply to my comment, so it's not a mistake that this is here.
I notice my comment being downvoted, and that's fine. I don't really care- but my statement stands; it's a far better use of your time to learn JavaScript and write extensions in VS Code to accomplish what you want. I realize this might get flagged and someone might be offended. I don't have patience today.
My JavaScript advice is multi-fold:
- You'll learn a language that's in active use and development, and the lingua franca of the web.
- You'll learn how extensions are created for VS Code, one of the most popular text editor and the greatest reach for sharing your work if you desire that.
- JavaScript is *fast*, Emacs is slow ; there are many other language problems that, shockingly, JavaScript is just better with.
- Waste less time debugging your text editor; not all of us (especially myself) have time to sink into becoming experts at Emacs. Emacs documentation is a bit esoteric and not that easy to grok, unless you already know ELisp.
- Need an off-the-shelf solution? VS Code most likely has that, and it's probably going to work
- Don't waste your time with dogma. EMacsers get in a tizzy fit over this and that, the right way to do things, to RTFM, etc. It's a community that has almost the same level of toxicity as Linux users.
I am someone who went all-in with Emacs for around 6 months. It is really an interesting piece of software and no one will deny that it can ostensibly do alot. One of the biggest issues I had was writing any form of prose - which made it lag so badly, it was nearly impossible to scroll. The collective solution, after posting on Reddit and searching via Google, was simply to use search - rather than scrolling to find what you're looking for.
I find manipulating buffers in Emacs fairly tedious, and I still believe that the mouse is a great invaluable tool not to be shunned. Some things are just easier and faster to manipulate with a pointer. I don't have a problem reaching for my mouse and returning to the keyboard without looking.
I tried to use it for journalling, and learning the ins-and-outs of Org-mode was fun. I liked org-capture. Then I realized, Obsidian was a better piece of tool. It handles prose just fine, and Markdown is much easier to remember (due to its ubiquitiness) than org-mode. And guess what languages extensions are written in? JavaScript.
Other comments:
> Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified.
Old JS code still work. JS has a reputation for being backwards compatible and taking a very long time to break any type of ABI. In the case of Electron, you are informed when things break - and you have time to update it. It's not like code changes happen under your feet, and things are breaking all of the time. [0] On top of that, Electron-based applications are almost guaranteed to work similarly on Windows, Mac and Linux. The same can't be said for Emacs, which suffer some fairly extreme performance issues on Windows.
> VS Code looks so boring in comparison.
It's just a tool. I can use themes, and syntax highlighting is great.
> but nvim and the like still suffer from being just text editors
And this is what makes it perfectly suited for its task.
> In Emacs, this is all very easy.
What makes emacs very easy? Every time I see anyone say Emacs is easy - they gush about writing code in ELisp, it's almost dogmatic. It's not about Emacs, it's about *ELisp*. I do believe the majority of Emacsers suffer from the IKEA effect[1] because the learning curve is so high that by the time they're able to build something in ELisp - they're also hit over the head with the Stockholm Syndrome[2].
My preferred solution would be to use an SQLite plugin in VS Code because that allows me to browse and query any code, rather than a fixed string. I don't need to write a new function, or try to manipulate Emacs buffers.
> Alternately, spend a weekend learning VS.Code and get on with doing real work.
Exactly my perspective.
[0] https://www.electronjs.org/docs/latest/breaking-changes