Ask HN: Resources to grok Emacs and use it well?

https://emacsformacosx.com/ is a very good port to MacOS. One advantage of Emacs on MacOS is that the Command key is not part of the traditional Emacs key bindings. This port uses Option for Meta and supports most of the usual MacOS Command key shortcuts, so you can use the familiar MacOS keys as well as the official Emacs key bindings.

I'm a moderately experienced Emacser - been using it heavily since 2009 (first encountered it in 2003). I have written a few small extensions and contributed features and bug fixes to bigger ones.

Credentials established, I cannot recommend this tutorial enough:

https://david.rothlis.net/emacs/tutorial.html

He walks you through most of the core of what makes Emacs great by showing you how to make a change to a project in the idiomatic Emacs way.

I would have learned it years faster had I started there.

Beyond that, learn basic Emacs keybindings via the tutorial, as others have suggested.

I started in Emacs but installed evil-mode a few years ago and have never looked back.

I do not recommend Spacemacs. Install the tools you want as you find you want them, so that you know what's doing what, and so you have a decent chance of knowing what broke things when something stops working.

Keep your packages in version control as part of your .emacs.d repository. That keeps updates and deleted packages from screwing you.

Use "use-package" (https://github.com/jwiegley/use-package) for configuring what you install. It's written by one of the Emacs maintainers and will help you do things right by default.

I'm not the best Emacser out there, but if you're curious, my config is on my GitHub account: https://github.com/NateEag/.emacs.d

Happy hacking.

Also seconding. Vanilla emacs is already extremely powerful, and if you're doing real work, you'll end up having to use hosts that don't have all of your wonderful enhancements installed. It's good to know vanilla emacs.

Beyond that, add language modes for anything you need that's not already included.

If you use 'git', 'magit' is very nice.

Beyond that, helm is interesting, though very large and kind of mind-blowing.

Recommend these in your ~/.emacs.d/init.el, to avoid being that guy:

    (setq-default show-trailing-whitespace 't)
    (setq-default indicate-empty-lines 't)

    ; try not to use tab characters ever when formatting code
    (setq-default indent-tabs-mode nil)

    (setq-default require-final-newline 'ask)
    (setq-default mode-require-final-newline 'ask)

I am keen to crowdsource a study of emacs workflow practices, where we can collect, compare and analyse different development practices among emacs users. This should help other emacs users to borrow modes/keybindings/specific techniques/tricks.

* Motivation

This is inspired by an ongoing conversation about emacs with a friend and a debugging interview that I really enjoyed.

* Exchanging emacs tips with a friend

A friend of mine is pretty proficient in emacs: org-mode all the things, written >500 LoC of elisp, tried several distributions. We still regularly teach each other about existing emacs functionality and exchange messages along the lines of: - I just found that there is a function foo, which I have made a keybinding foo and can now search open a tab with a SO search with text from the clipboard - whaaat? That's super useful! - I know, right?

He works with a couple of greybeards, who also seem to be constantly finding emacs functionality that makes their lives easier, which suggests it would be beneficial for all of us to watch others in emacs.

* Interview

I was given a real git repo that I needed to load into my environment (spacemacs on Linux) to debug and fix failing tests. They sat me down during the onsite (the days when we would go to interview in person), told me to download the repo from the URL, told me how to run the tests (after activating the python venv) and watched me debug and fix failing tests - only 5 were failing from about 100. The interviewers were not proficient in emacs, but I felt that they could follow my thought process and workflow. I had only recently set up python dap-mode and felt clunky navigating in pdb through dap, so ended up print debugging.

It made me think how interesting it would be to watch other people with different backgrounds and experiences debug the same problem and how often I would learn new tricks or debugging techniques. Having a good understanding of the problem and the code allows you to focus on the activity of programming and watch out for new ways of tackling the same problem.

* What will we investigate

Furthermore, it might be interesting to see what debugging practices are statistically more succesful in tracking down the bug faster (and control them for overall years of programming experience and emacs proficiency).

If our sample is big enough we can answer questions like: Correlation between overall years of programming experience and debugging time? Who is faster at debugging: printf or gdb debugger people? Which keybindings and modes are most frequent across users? Is there a correlation between having custom elisp functions and debugging time?

* Format

I will prepare a representative repo in the most popular language (I am most comfortable in Python, happy to consider other languages, if people prefer), bury some bugs in it (that will be easy), administer the study and summarise the findings in a spreadsheet/write-up.

Following the debugging session outlined above. Every participant:

starts recording their screen

Starts a fresh emacs instance with their config and loads a emacs lisp script that we provide for printing keypresses and recording keypresses + function calls to a log file.

download the prepared repo

run tests

investigate failing tests

fix them

commit their changes

The participant ends the screen recording session before sending me

   - the video to me or youtube/dailymotion URL 
   - plaintext keylog history
   -  link to their elisp config

I appreciate logging keypresses/function calls might feel intrusive, so if you are uncomfortable doing that - don't! At the same time, if we want to share good debugging practices and general emacs tricks - I see this as the most impactful way to share techniques and elisp snippets.

I watch it, sumarise the findings and present a write-up.

Who is interested?

I was a vi user that had to ramp up quickly on a clojure project. Being new to clojure, I choose not to emacs at the same time as clojure. Spacemacs was lifesaver for me, given clojure experience in vi + plugins is subpar.