10 ms·

Master Emacs in one year

141 points by oumua_don17 4y ago

wkat4242 4y ago
One year is not bad to master a whole OS!
adastra22 4y ago
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.
- djaouen 4y ago
  I guess programming [1] isn’t worth learning, then? [1] https://norvig.com/21-days.html https://norvig.com/21-days.html
  - adastra22 4y ago
    “UI/UX”
    - omnicognate 4y ago
      "Mastering" emacs (certainly any version of "mastering" it that takes a whole year) requires learning a programming language, elisp. This is because emacs isn't an editor. It's a language and environment for rapiy developing textual user interfaces (TUIs) and "customising" or "configuring" it is programming. To just learn to operate it as a text editor certainly doesn't take a year, but if that's the approach you're going to take I wouldn't recommend emacs. Use VS Code or a JetBrains IDE or whatever instead. The linked article isn't very good, BTW. If you're interested in actually mastering emacs, the book "Mastering Emacs" [1], whose author comments here regularly, is the place to start. [1] https://www.masteringemacs.org/ https://www.masteringemacs.org/
      - illiarian 4y ago
        > To just learn to operate it as a text editor certainly doesn't take a year, but if that's the approach you're going to take I wouldn't recommend emacs. Use VS Code or a JetBrains IDE or whatever instead The way this sentence is constructed, it makes VS Code and Jetbrains IDEs sound like just text editors :) In all seriousness though, for the vast majority of programmers Emacs (or vim for that matter) has no value compared to, say, Jetbrains IDEs. You need dozens of plugins and an unknown number lines of arcane configurations just to have a semblance of a small part of functionality that those IDEs have out of the box.
        omnicognate 4y ago
        That certainly wasn't the intention of that sentence. Re "has no value" - wevs. It has massive value to me and to a community large enough to have continually supplied me with new and useful functionality and resources for 20 years, most of which have been spent using it alongside either Visual Studio (not "Code") or a JetBrains IDE (mostly Rider, some PyCharm). You use whatever tools you like and I'll decide what tools have value to me.
    - bigpeopleareold 4y ago
      I think a programming language can be viewed as a UI and having a UX: - UI: It's a text based UI that is lazily evaluated (that is, there is always some compilation and/or execution to specifically run for the commands to execute. This UI would fit a certain model of computation, itself being a domain and use-case. - UX: The ergonomics of a programming language, like it's usefulness, accessibility of concepts, its surrounding toolchain, is part of the experience of using this interface to the computer. There is also talk even here on HN about PL features and their utility. That, to me, is a form of user experience. I say this because I think about a programming language's toolchain as the make-or-break aspect of its utility of a language. Can I interface with it well enough without anxiety or anger? :) But, these "lazily evaluated" tools I think form in an aggregate as a user interface to me.
- blahgeek 4y ago
  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.
  - adastra22 4y ago
    It’s a text editor, mail reader, todo manager, etc. none of those things should take a year to master, even in aggregate.
    - diffeomorphism 4y ago
      Yep, exactly. So obviously that is not the case.
- otabdeveloper4 4y ago
  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.
  - ParetoOptimal 4y ago
    The problem is people don't use it's disoverability or built-in help. They do a web search that quickly gives bad to poor advice.
- diffeomorphism 4y ago
  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"
- wolpoli 4y ago
  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.
  - jb1991 4y ago
    > it has a one-of-a kind shortcut/user interface The system-wide OS keyboard shortcuts for basic text editing in macOS are the same as emacs. I discovered this accidentally and people wonder why I can navigate basic stuff on the mac so well and my answer is "I used emacs for many years."
    - wolpoli 4y ago
      Thanks! I was not aware of that.
      - mvdwoord 4y ago
        GNU readline is also all over the place and has emacs like keybindings. https://tiswww.case.edu/php/chet/readline/rltop.html https://tiswww.case.edu/php/chet/readline/rltop.html
    - leobg 4y ago
      Which shortcuts? You have a link to a list? I only know Cmd-left/right to skip words. But anything more fancy?
      - jb1991 4y ago
        if you are using left/right arrow keys, that is not emacs. Control with F, B, A, E, K, etc are the ones I'm talking about.
- Iridescent_ 4y ago
  I would not imagine mastering VSCode or any Jetbrains suite product to take any less time.
  - jb1991 4y ago
    This. Jetbrains is also awesome but you don't just pick it up and msater it in short time.
- raverbashing 4y ago
  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
- u801e 4y ago
  > 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.
- spindle 4y ago
  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!
  - adastra22 4y ago
    I did and I regret it.
- textread 4y ago
  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.
  - oldsecondhand 4y ago
    I prefer JEdit to Emacs for a programmable editor, but I mostly just use IntelliJ anyway. JEdit carries the philosophy of Emacs, but the UI isn't stuck in the 70s.
    - textread 4y ago
      I just read the JEdit.org homepage. I am really intriuged by this comment over there and also your recommendation: jEdit is a mature programmer's text editor with hundreds (counting the time developing plugins) of person-years of development behind it. Would you please point me to a good resource to learn more about JEdit for someone with Emacs/Vim background.
  - adastra22 4y ago
    For code editing, pick your IDE. For mail reading, pick your mail reader. For todo, pick your favorite todo app. They’re all better UI/UX.
dang 4y ago
Related: Master Emacs in one year - https://news.ycombinator.com/item?id=16424934 https://news.ycombinator.com/item?id=16424934 - Feb 2018 (5 comments) Master Emacs in one year - https://news.ycombinator.com/item?id=8079083 https://news.ycombinator.com/item?id=8079083 - July 2014 (116 comments)
posed 4y ago
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.
- chungy 4y ago
  Once you go Emacs, you never go back.
  - chongli 4y ago
    I started on vim. Switched to emacs for a couple years, then switched back. The biggest issue with emacs for me is ergonomic. It relies way too much on the pinkie finger for everything and it gets really painful when you get RSI in your pinkie. It’s fine if you’re going slow and taking your time with things, but then why learn a complicated editor in the first place if you’re just going to go slow? Yes, I tried evil mode for a while as well. The problem with that is that it’s, well, evil. An unholy alliance of drastically different paradigms, the setup just becomes way too complicated. You lose the main advantage of emacs modelessness and are back to switching modes like vim, only now you also have all of the emacs key bindings to deal with. Why not just go back to vim and simplify your life? That’s what I did!
    - JonChesterfield 4y ago
      It's really easy to use a different key for that. Pretty sure the keyboards it was written for had a different layout to today's off the shelf ones.
    - G3rn0ti 4y ago
      Well, if your pinky is such an issue why not bind „C-“ to caps lock instead? I‘ve heard many people doing that and be happy w/o the effort of learning the evil mode framework (which I wouldn’t suggest beginners doing despite many prominent Emacs evangelists using evil).
    - AugurCognito 4y ago
SanderNL 4y ago
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.
- drichel 4y ago
  "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.
  - nsomaru 4y ago
    To follow the path Look to the master Follow the master Walk with the master See through the master Become the master
  - SanderNL 4y ago
    Yes, you copy it (do what they did). Not take photographs of their work.
- dkarl 4y ago
  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.
precompute 4y ago
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.
akho 4y ago
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.
mkl95 4y ago
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.
- BeFlatXIII 4y ago
  > 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.
- User23 4y ago
  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. [1] http://www.xpilot.org/about/ http://www.xpilot.org/about/
textread 4y ago
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. I just perused through the tutorial. This is some horrible advice, IMHO. 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 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. 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
- cc_ashby 4y ago
  Emacs from scratch is the way to go. Added abstractions are usually not good enough to completely replace fiddling around with vanilla Emacs.
- kickaha 4y ago
  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.
- ehecatl42 4y ago
  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 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!
deafpolygon 4y ago
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.
- G3rn0ti 4y ago
  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.
- precompute 4y ago
  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.
  - ColonelPhantom 4y ago
    What makes it easier to write in ELisp compared to JS? Also, other text editors got on the 'real programming language' train too, like Neovim with its support for Lua. There's also Lite XL which is almost fully written in Lua itself. Does ELisp still have a big advantage there?
    - precompute 4y ago
      Sure. Elisp is very well-integrated with the editor itself, because that's what emacs is written in. There are some primitive functions that written in C that everything builds on top of. This makes writing functions an extension of the text editing process itself. This is why it's truly extensible. You don't get penalized for writing your own functions, they exist at the same rank as what emacs ships with. Writing functions in lua is fine, but nvim and the like still suffer from being just text editors, and most things that interact with the operating system / syscalls or change/traverse the UI require quite a lot of legwork. In Emacs, this is all very easy. Depending on what you need, you can be perfectly satisfied with vim and a couple of plugins. However, after realizing how easy it was to write functions in elisp, I more or less moved all my text / file editing to Emacs, along with most batch functions. For example, here's a function to insert a formatted date in the current buffer: (defun timestamp () "Insert string for the current time formatted like '2:34 PM' or 1507121460" (interactive) (insert (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] "))) You'd have to consult the docs for writing this trivial function in literally any other text editor. In emacs, you can `C-h` for everything, and this program will always run properly, because you're using functions that are used by emacs internally. Chaining functions: (defun org-id-create-copy () "org-id-get-create and then org-id-copy" (interactive) (org-id-get-create) (org-id-copy)) Utilizing inbuilt syntax for a major mode in your custom function: (defun org-delete-subtree () "Delete the current subtree" (interactive) (let ((org-heading-text (nth 4 (org-heading-components)))) (save-restriction (org-narrow-to-subtree) (kill-region (point-min) (point-max)) (widen) (kill-whole-line 1)) (message "Heading deleted : %s" org-heading-text))) Using recorded macros as functions: (fset 'throwtext-c "x\C-w\C-wGp") (fset 'kindle-clippings-to-org-macro (save-excursion (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j ?d ?d ?V ?\C-s ?f ?n] 0 "%d"))) Capturing (copying / appending to a certain location, depending on your config / provided template) highlighted text from a PDF file opened in Emacs: (defun org-capture-pdf-c (action) "Capture the active region of the pdf-view buffer." (let* ((pdf-buf-name (plist-get org-capture-plist :original-buffer)) (pdf-buf (get-buffer pdf-buf-name))) (if (buffer-live-p pdf-buf) (cond ((= action 1) (with-current-buffer pdf-buf (buffer-name))) ((= action 2) (with-current-buffer pdf-buf (buffer-file-name))) ((= action 3) (with-current-buffer pdf-buf (if (pdf-view-active-region-p) (car (pdf-view-active-region-text)) (ignore-errors (buffer-substring-no-properties (region-beginning) (region-end)))))) ((= action 4) (with-current-buffer pdf-buf (number-to-string (pdf-view-current-page))))) (user-error "Buffer %S not alive." pdf-buf-name)))) Traversing text programmatically: (defun comments-skip-c () "Skips to the line after the next comment ends" (interactive) (search-forward-regexp comment-start-skip) (while (string-match comment-start-skip (buffer-substring (line-beginning-position) (line-end-position))) (forward-line))) Making windows larger by a ratio: (defun make-window-larger-c (&optional ratio) "Makes the current window larger or smaller. RATIO is the ratio used, default is 0.618. It switches the width before the height." (interactive) (save-excursion (let\* ((postv (if olivetti-mode (progn (olivetti-mode -1) t) nil)) (wwidth (window-width)) (wheight (window-height)) (fwidth (frame-width)) (fheight (frame-height)) (ratio (if ratio ratio 0.618)) (fl/fheight (floor (\* ratio fheight))) (fl/fwidth (floor (\* ratio fwidth)))) (if (window-full-width-p) (if (window-full-height-p) (message "Nothing to resize.") (if (>= wheight fl/fheight) (if (>= wwidth fl/fwidth) (message "Nothing to resize.") (enlarge-window (- fl/fwidth wwidth) t)) (enlarge-window (- fl/fheight wheight)))) (if (>= wwidth fl/fwidth) (if (>= wheight fl/fheight) (message "Nothing to resize.") (enlarge-window (- fl/fheight wheight))) (enlarge-window (- fl/fwidth wwidth) t))) (if postv (olivetti-mode 1))))) Querying a SQLite DB for entries and showing them in a selectable list; selected entry is copied to clipboard. (require 'sqlite3) (defun kill-new-from-global-paste-c () (interactive) (let ((mylist '())) (let* ((dbh (sqlite3-open "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-open-readonly)) (stmt (sqlite3-prepare dbh "select * from text order by id desc limit 500"))) (while (= sqlite-row (sqlite3-step stmt)) (cl-destructuring-bind (id text) (sqlite3-fetch stmt) (setq mylist (nconc mylist (list text))))) (sqlite3-finalize stmt) (sqlite3-close dbh)) (kill-new (let* ((vertico-sort-function nil) (rlist (completing-read-multiple " " mylist)) (rstr "")) (while (length> rlist 0) (setq rstr (concat rstr (pop rlist) "\n"))) rstr)))) EDIT: Oh, and changing the "face" (appearance) of text is also very easy. It's easy to make your own syntax highlighting rules or even highlight stuff according to a regex temporarily.
anthk 4y ago
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.
- G3rn0ti 4y ago
  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.
- nurbl 4y ago
  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.
NelsonMinar 4y ago
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!)
- SeqDesign 4y ago
  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.
- Koshkin 4y ago
  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.”)
- dkarl 4y ago
  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.
- thiht 4y ago
  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.
- d0mine 4y ago
  "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.
guidoism 4y ago
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.
- bradleybuda 4y ago
  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.
  - guidoism 4y ago
    Is it because the vi-type editors are a lot better or VSCode or just the whole IDE thing (not sure if this is still a thing these days)?
rbc 4y ago
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.

141 points by oumua_don17 4y ago

One year is not bad to master a whole OS!

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.

djaouen 4y ago
I guess programming [1] isn’t worth learning, then? [1] https://norvig.com/21-days.html https://norvig.com/21-days.html
- adastra22 4y ago
  “UI/UX”
  - omnicognate 4y ago
    "Mastering" emacs (certainly any version of "mastering" it that takes a whole year) requires learning a programming language, elisp. This is because emacs isn't an editor. It's a language and environment for rapiy developing textual user interfaces (TUIs) and "customising" or "configuring" it is programming. To just learn to operate it as a text editor certainly doesn't take a year, but if that's the approach you're going to take I wouldn't recommend emacs. Use VS Code or a JetBrains IDE or whatever instead. The linked article isn't very good, BTW. If you're interested in actually mastering emacs, the book "Mastering Emacs" [1], whose author comments here regularly, is the place to start. [1] https://www.masteringemacs.org/ https://www.masteringemacs.org/
    - illiarian 4y ago
      > To just learn to operate it as a text editor certainly doesn't take a year, but if that's the approach you're going to take I wouldn't recommend emacs. Use VS Code or a JetBrains IDE or whatever instead The way this sentence is constructed, it makes VS Code and Jetbrains IDEs sound like just text editors :) In all seriousness though, for the vast majority of programmers Emacs (or vim for that matter) has no value compared to, say, Jetbrains IDEs. You need dozens of plugins and an unknown number lines of arcane configurations just to have a semblance of a small part of functionality that those IDEs have out of the box.
      - omnicognate 4y ago
        That certainly wasn't the intention of that sentence. Re "has no value" - wevs. It has massive value to me and to a community large enough to have continually supplied me with new and useful functionality and resources for 20 years, most of which have been spent using it alongside either Visual Studio (not "Code") or a JetBrains IDE (mostly Rider, some PyCharm). You use whatever tools you like and I'll decide what tools have value to me.
  - bigpeopleareold 4y ago
    I think a programming language can be viewed as a UI and having a UX: - UI: It's a text based UI that is lazily evaluated (that is, there is always some compilation and/or execution to specifically run for the commands to execute. This UI would fit a certain model of computation, itself being a domain and use-case. - UX: The ergonomics of a programming language, like it's usefulness, accessibility of concepts, its surrounding toolchain, is part of the experience of using this interface to the computer. There is also talk even here on HN about PL features and their utility. That, to me, is a form of user experience. I say this because I think about a programming language's toolchain as the make-or-break aspect of its utility of a language. Can I interface with it well enough without anxiety or anger? :) But, these "lazily evaluated" tools I think form in an aggregate as a user interface to me.
blahgeek 4y ago
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.
- adastra22 4y ago
  It’s a text editor, mail reader, todo manager, etc. none of those things should take a year to master, even in aggregate.
  - diffeomorphism 4y ago
    Yep, exactly. So obviously that is not the case.
otabdeveloper4 4y ago
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.
- ParetoOptimal 4y ago
  The problem is people don't use it's disoverability or built-in help. They do a web search that quickly gives bad to poor advice.
diffeomorphism 4y ago
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"
wolpoli 4y ago
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.
- jb1991 4y ago
  > it has a one-of-a kind shortcut/user interface The system-wide OS keyboard shortcuts for basic text editing in macOS are the same as emacs. I discovered this accidentally and people wonder why I can navigate basic stuff on the mac so well and my answer is "I used emacs for many years."
  - wolpoli 4y ago
    Thanks! I was not aware of that.
    - mvdwoord 4y ago
      GNU readline is also all over the place and has emacs like keybindings. https://tiswww.case.edu/php/chet/readline/rltop.html https://tiswww.case.edu/php/chet/readline/rltop.html
  - leobg 4y ago
    Which shortcuts? You have a link to a list? I only know Cmd-left/right to skip words. But anything more fancy?
    - jb1991 4y ago
      if you are using left/right arrow keys, that is not emacs. Control with F, B, A, E, K, etc are the ones I'm talking about.
Iridescent_ 4y ago
I would not imagine mastering VSCode or any Jetbrains suite product to take any less time.
- jb1991 4y ago
  This. Jetbrains is also awesome but you don't just pick it up and msater it in short time.
raverbashing 4y ago
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
u801e 4y ago
> 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.
spindle 4y ago
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!
- adastra22 4y ago
  I did and I regret it.
textread 4y ago
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.
- oldsecondhand 4y ago
  I prefer JEdit to Emacs for a programmable editor, but I mostly just use IntelliJ anyway. JEdit carries the philosophy of Emacs, but the UI isn't stuck in the 70s.
  - textread 4y ago
    I just read the JEdit.org homepage. I am really intriuged by this comment over there and also your recommendation: jEdit is a mature programmer's text editor with hundreds (counting the time developing plugins) of person-years of development behind it. Would you please point me to a good resource to learn more about JEdit for someone with Emacs/Vim background.
- adastra22 4y ago
  For code editing, pick your IDE. For mail reading, pick your mail reader. For todo, pick your favorite todo app. They’re all better UI/UX.

dang 4y ago

Related: Master Emacs in one year - https://news.ycombinator.com/item?id=16424934 https://news.ycombinator.com/item?id=16424934 - Feb 2018 (5 comments) Master Emacs in one year - https://news.ycombinator.com/item?id=8079083 https://news.ycombinator.com/item?id=8079083 - July 2014 (116 comments)

posed 4y ago

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.

chungy 4y ago
Once you go Emacs, you never go back.
- chongli 4y ago
  I started on vim. Switched to emacs for a couple years, then switched back. The biggest issue with emacs for me is ergonomic. It relies way too much on the pinkie finger for everything and it gets really painful when you get RSI in your pinkie. It’s fine if you’re going slow and taking your time with things, but then why learn a complicated editor in the first place if you’re just going to go slow? Yes, I tried evil mode for a while as well. The problem with that is that it’s, well, evil. An unholy alliance of drastically different paradigms, the setup just becomes way too complicated. You lose the main advantage of emacs modelessness and are back to switching modes like vim, only now you also have all of the emacs key bindings to deal with. Why not just go back to vim and simplify your life? That’s what I did!
  - JonChesterfield 4y ago
    It's really easy to use a different key for that. Pretty sure the keyboards it was written for had a different layout to today's off the shelf ones.
  - G3rn0ti 4y ago
    Well, if your pinky is such an issue why not bind „C-“ to caps lock instead? I‘ve heard many people doing that and be happy w/o the effort of learning the evil mode framework (which I wouldn’t suggest beginners doing despite many prominent Emacs evangelists using evil).
  - AugurCognito 4y ago

SanderNL 4y ago

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.

drichel 4y ago
"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.
- nsomaru 4y ago
  To follow the path Look to the master Follow the master Walk with the master See through the master Become the master
- SanderNL 4y ago
  Yes, you copy it (do what they did). Not take photographs of their work.
dkarl 4y ago
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.

precompute 4y ago

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.

akho 4y ago

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.

mkl95 4y ago

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.

BeFlatXIII 4y ago
> 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.
User23 4y ago
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. [1] http://www.xpilot.org/about/ http://www.xpilot.org/about/

textread 4y ago

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. I just perused through the tutorial. This is some horrible advice, IMHO. 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 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. 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

cc_ashby 4y ago
Emacs from scratch is the way to go. Added abstractions are usually not good enough to completely replace fiddling around with vanilla Emacs.
kickaha 4y ago
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.
ehecatl42 4y ago
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 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!

deafpolygon 4y ago

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.

G3rn0ti 4y ago
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.
precompute 4y ago
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.
- ColonelPhantom 4y ago
  What makes it easier to write in ELisp compared to JS? Also, other text editors got on the 'real programming language' train too, like Neovim with its support for Lua. There's also Lite XL which is almost fully written in Lua itself. Does ELisp still have a big advantage there?
  - precompute 4y ago
    Sure. Elisp is very well-integrated with the editor itself, because that's what emacs is written in. There are some primitive functions that written in C that everything builds on top of. This makes writing functions an extension of the text editing process itself. This is why it's truly extensible. You don't get penalized for writing your own functions, they exist at the same rank as what emacs ships with. Writing functions in lua is fine, but nvim and the like still suffer from being just text editors, and most things that interact with the operating system / syscalls or change/traverse the UI require quite a lot of legwork. In Emacs, this is all very easy. Depending on what you need, you can be perfectly satisfied with vim and a couple of plugins. However, after realizing how easy it was to write functions in elisp, I more or less moved all my text / file editing to Emacs, along with most batch functions. For example, here's a function to insert a formatted date in the current buffer: (defun timestamp () "Insert string for the current time formatted like '2:34 PM' or 1507121460" (interactive) (insert (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] "))) You'd have to consult the docs for writing this trivial function in literally any other text editor. In emacs, you can `C-h` for everything, and this program will always run properly, because you're using functions that are used by emacs internally. Chaining functions: (defun org-id-create-copy () "org-id-get-create and then org-id-copy" (interactive) (org-id-get-create) (org-id-copy)) Utilizing inbuilt syntax for a major mode in your custom function: (defun org-delete-subtree () "Delete the current subtree" (interactive) (let ((org-heading-text (nth 4 (org-heading-components)))) (save-restriction (org-narrow-to-subtree) (kill-region (point-min) (point-max)) (widen) (kill-whole-line 1)) (message "Heading deleted : %s" org-heading-text))) Using recorded macros as functions: (fset 'throwtext-c "x\C-w\C-wGp") (fset 'kindle-clippings-to-org-macro (save-excursion (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j ?d ?d ?V ?\C-s ?f ?n] 0 "%d"))) Capturing (copying / appending to a certain location, depending on your config / provided template) highlighted text from a PDF file opened in Emacs: (defun org-capture-pdf-c (action) "Capture the active region of the pdf-view buffer." (let* ((pdf-buf-name (plist-get org-capture-plist :original-buffer)) (pdf-buf (get-buffer pdf-buf-name))) (if (buffer-live-p pdf-buf) (cond ((= action 1) (with-current-buffer pdf-buf (buffer-name))) ((= action 2) (with-current-buffer pdf-buf (buffer-file-name))) ((= action 3) (with-current-buffer pdf-buf (if (pdf-view-active-region-p) (car (pdf-view-active-region-text)) (ignore-errors (buffer-substring-no-properties (region-beginning) (region-end)))))) ((= action 4) (with-current-buffer pdf-buf (number-to-string (pdf-view-current-page))))) (user-error "Buffer %S not alive." pdf-buf-name)))) Traversing text programmatically: (defun comments-skip-c () "Skips to the line after the next comment ends" (interactive) (search-forward-regexp comment-start-skip) (while (string-match comment-start-skip (buffer-substring (line-beginning-position) (line-end-position))) (forward-line))) Making windows larger by a ratio: (defun make-window-larger-c (&optional ratio) "Makes the current window larger or smaller. RATIO is the ratio used, default is 0.618. It switches the width before the height." (interactive) (save-excursion (let\* ((postv (if olivetti-mode (progn (olivetti-mode -1) t) nil)) (wwidth (window-width)) (wheight (window-height)) (fwidth (frame-width)) (fheight (frame-height)) (ratio (if ratio ratio 0.618)) (fl/fheight (floor (\* ratio fheight))) (fl/fwidth (floor (\* ratio fwidth)))) (if (window-full-width-p) (if (window-full-height-p) (message "Nothing to resize.") (if (>= wheight fl/fheight) (if (>= wwidth fl/fwidth) (message "Nothing to resize.") (enlarge-window (- fl/fwidth wwidth) t)) (enlarge-window (- fl/fheight wheight)))) (if (>= wwidth fl/fwidth) (if (>= wheight fl/fheight) (message "Nothing to resize.") (enlarge-window (- fl/fheight wheight))) (enlarge-window (- fl/fwidth wwidth) t))) (if postv (olivetti-mode 1))))) Querying a SQLite DB for entries and showing them in a selectable list; selected entry is copied to clipboard. (require 'sqlite3) (defun kill-new-from-global-paste-c () (interactive) (let ((mylist '())) (let* ((dbh (sqlite3-open "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-open-readonly)) (stmt (sqlite3-prepare dbh "select * from text order by id desc limit 500"))) (while (= sqlite-row (sqlite3-step stmt)) (cl-destructuring-bind (id text) (sqlite3-fetch stmt) (setq mylist (nconc mylist (list text))))) (sqlite3-finalize stmt) (sqlite3-close dbh)) (kill-new (let* ((vertico-sort-function nil) (rlist (completing-read-multiple " " mylist)) (rstr "")) (while (length> rlist 0) (setq rstr (concat rstr (pop rlist) "\n"))) rstr)))) EDIT: Oh, and changing the "face" (appearance) of text is also very easy. It's easy to make your own syntax highlighting rules or even highlight stuff according to a regex temporarily.

anthk 4y ago

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.

G3rn0ti 4y ago
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.
nurbl 4y ago
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.

NelsonMinar 4y ago

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!)

SeqDesign 4y ago
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.
Koshkin 4y ago
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.”)
dkarl 4y ago
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.
thiht 4y ago
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.
d0mine 4y ago
"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.

guidoism 4y ago

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.

bradleybuda 4y ago
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.
- guidoism 4y ago
  Is it because the vi-type editors are a lot better or VSCode or just the whole IDE thing (not sure if this is still a thing these days)?

rbc 4y ago

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.