HN Explorer

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

292 points by AnonC ↗ HN
With reference to the other post here (https://news.ycombinator.com/item?id=22875106), I’m once again fascinated by Emacs and the following it has. I know vi (learned it quite sometime ago) and though I’m not a power user, I can do a lot of things in vi without putting in much effort or searching online for solutions.

So I’m here to ask for resources — text based tutorials, video tutorials and what not — that would help someone grok Emacs (from a novice level) and get into the Emacs way of doing things (including elisp?).

I would also like recommendations on what (package/source) you consider as the best to install on macOS and on Linux.

178 comments

[ 0.21 ms ] story [ 1257 ms ] thread
znpy
follow the tutorial! it will guide you through the learning :)
gct
If you're currently a vi user, I'd recommend spacemacs (https://www.spacemacs.org/) to soften the learning curve. It comes batteries included (as opposed to a stock emacs install which requires a _lot_ of customization) and uses evil mode (vi keybindings) by default. You can expose yourself to more and more of the emacs way slowly.

Also emacs is largely self-documenting. Learn the keys for querying documentation first thing. You can search for current keybindings, what a given function _does_, etc all live while you're using it.

tams
Spacemacs is great, albeit slow at times.

On the evil front there is also Doom Emacs (https://github.com/hlissner/doom-emacs) which is better optimized and is still pretty full-featured.

aladine
Doom Emacs is a collection of many recommendated packages. For someone doesn't use evil much like me, I can turn it off in the config file. Using Doom Emacs is highly recommended for new comers to Emacs
dominotw
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.
Koshkin
https://duckduckgo.com/?t=ffsb&q=learn+emacs&ia=web

Pretty good resources right at the top.

AnonC
Thank you for pointing that out. I should’ve checked that out first, but I thought the collective mind here may be a lot more helpful (so far all the comments here have been very helpful to me, including yours).
vhodges
The tutorial and M-x apropos is how I learned so many (many) moons ago.
rwnspace
This is what I've done the past couple weeks and it's going pretty well:

Start with plain Emacs. Print/write out the popular cheatsheets. Just make sure you know how to exit, access the documentation, and move around the windows/frames/buffers. Get Melpa & install some packages. Play with the config, adding keybindings, figure out hooks and so on. Copy some elisp functions from dotfiles on Github. Spam the documentation command on everything. Get frustrated with how much tinkering you need to do to get the crazy setups you've seen on blogposts. Stay motivated by consuming more content about custom setups. Discover the magic of magit and parinfer and dired. Look up some of the org-mode/PIM heroes on github, usernames: novoid, alphapapa, karlicoss

Install Doom. Tinker with it a bit. Take notes of your learning in an org file. Tinker some more. Go back to plain emacs for a bit. Then try spacemacs. Go straight back to Doom because it's faster and you now understand enough about emacs to be scared of spacemacs' layers.

Below are some links to help you along the way.

http://ergoemacs.org/emacs/blog.html

https://sachachua.com/blog/

https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf

https://orgmode.org/worg/orgcard.html

https://cestlaz.github.io/stories/emacs/

https://www.youtube.com/watch?v=0g9BcZvQbXU

https://zaiste.net/doomcasts/

dimitar
Out of box / vanilla Emacs is pretty confusing doesn't include many popular packages - that is why some pre-made configs are very popular. On the other hand they might overwhelm you with features and very opinionated decisions.

If you want something close to what most users probably have setup and yet still close to vanilla you can give Emacs Prelude a try: https://prelude.emacsredux.com/en/latest/

I started with it, tried out the package selection, but then started a smaller config from scratch with what I liked from it.

Also good links: https://www.masteringemacs.org/reading-guide http://emacsrocks.com

I don't believe one should restrict oneself to a single editor, but rather follow a path of least resistance - Emacs is actually the path of least resistance when you want to have a custom editing experience.

Overall I use four editors Emacs, vi, notepad++ and VS Code. Emacs when doing Clojure or any other code so I can have something that is very convenient for me, vi and notepad++ on machines where I don't want to setup a config or where I do only simple text editing and VS Code where I would ocasionally need to install a plug-in, but I don't need to use it often.

stakkur
I started using Emacs in earnest a few years ago, especially Org-Mode. At first, I tried every customization I came across and loaded up my init file with all the cool mods. But when things went wrong, I had no clue how to fix them.

So after about a year I started over, resetting my config and using Emacs customization over custom elisp writing to get a working init file. It helped me learn a lot. This is the path I recommend: do small customizations using Emacs' built-in features, then learn elisp later.

I learned a lot from this CS prof's videos, and it's a good, practical learning path I'd recommend: https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpF...

If you're into writing, I maintain a list of resources for writing with Emacs: https://github.com/thinkhuman/writingwithemacs

shivekkhurana
I learnt from the same professor! His youtube series is well done.
rglullis
Saying that as someone using Emacs for at least 20 years: ignore the zealots, get rid of this FOMO and ask yourself if there are 3 things missing from your tools, things that you would like to have a better way of doing. For these things, find someone experienced with Emacs and ask them to show you how they do it.

Unless your passion is in going meta and focus on building the tools instead of using them, chances are that your current tools can do what you need just fine.

cardiffspaceman
Indeed. There is some satisfaction in customizing things in order to get things done more easily, but there is more satisfaction, hopefully, in shipping code.

I used TECO to get grades back in the day, on a DEC-10. People used to write BASIC interpreters in TECO for fun. Then I went into the wilderness, where every system I used was uncustomizable. And then DOS, where Turbo C and Brief were kings. Eventually the system I used was Windows, and MS Developer Studio (before Visual Studio) had some macro recording capability. Then I joined a company where everything was just more convenient if you put Linux on your desktop, and for my limited Windows work, one of the Windows ports of Emacs was adequate, and a couple of our brightest were always using Emacs. These were the guys I wanted to emulate so I started using Emacs. But then I branched off and started using Eclipse, because I couldn't get ctags to work well enough with all the C++ code I was working with. Eclipse's remote solution seems to be dead so now I'm using Code.

I don't miss TECO.

Nextgrid
Agreed, and this is not specific to Emacs or even text editors. The same can be applied to operating systems or even hardware. There are a lot of people out there that will spend more time tweaking and playing with their tools than actually using them. It's fine if you're doing it for the experience or for enjoyment, but don't delude yourself into thinking you're actually spending your time productively and that all of that work is "eventually" gonna pay off.

My biggest increase in productivity was to stop tweaking and just switch to a mainstream OS and use a mainstream editor using the stock config as much as possible (I only changed a handful of settings). I honestly can't think of anything in my current workflow that is a bottleneck to my productivity; the tools are fast enough that the bottleneck is now my brain and thoughts and tweaking the tools won't fix that.

shermanmccoy
You may just want something a bit snappier, say if you are coming from massive bloatware IDE land?
rglullis
OP says he is experienced with vi, so it is not his case and I don't want to be playing a game of "unlikely hypotheticals"

But, even if that were the case, the recommendation would be to either (a) find a lighter alternative to the used IDE or (b) switch to an IDE that is plugin-based to remove all of the "bloatware". At no point I would be telling people that the first alternative for them to "be fast" is to join the church of Emacs.

Fuck, I worked with junior developers who were more comfortable after I showed them they could work with gedit + terminal instead of cargo-culting whatever tool some nerdy senior used.

All I am asking is to not be like those photographers that spend more time on forums discussing about equipment than actually taking pictures, or audiophiles that focus so much on testing their equipment that they forget to enjoy the music. Unless you are a camera maker/speaker designer/software tool developer, focusing on the tools instead of the product is quite a stupid way to live.

catern
Do the tutorial (C-h t), and then read the manual (C-h r).
kfogel
Single best thing you can do:

Find an expert Emacs user who's willing to help, and have them watch you in person, even for just a short time, as you use Emacs to do things. Lather, rinse, repeat. Make sure they show you how to use the built-in help and feature-exploration mechanisms (but they'll know to do that anyway, if they're an expert).

kfogel
(Okay, well, I guess this was a particularly bad time to recommend a specifically in-person help session :-). Live video would work too, as long as the resolution is high enough for them to see what you're doing.)
lainwashere
As others have said, the tutorial is the best place to start (C-h t). After that for any other thing you need to learn in emacs the info will probably have it (C-h i or M-x info). Emacs users usually spend much time configuring their “operating system” till they’re satisfied, by modifying the init.el, but you can get a popular config already made [0][1]. My biggest recommendation after understanding how emacs works, if you use/prefer vi binds, is install evil-mode [2]. It’s essentially a vi layer on top of emacs, and is very functional.

edit: If you use MacOS, Yamamoto Mitsuharu‘s emacs-mac [3] is my recommendation, as for linux the version from your distros package manager should be apt. ;)

[0] https://github.com/hlissner/doom-emacs

[1] https://github.com/syl20bnr/spacemacs

[2] https://github.com/emacs-evil/evil

[3] https://bitbucket.org/mituharu/emacs-mac

kabdib
Emacs user here, it's been my go-to editor for about 40 years.

I have a few customizations, not many. My .emacs file is 63 lines long, doesn't include any other files, and mostly just tweaks some key bindings and turns off features that I don't like. The only modes I use are built-in ones (e.g., C-mode, auto-wrapping text mode, etc.). I can't write elisp without a reference manual, and I think that's okay.

I suggest:

- not installing a bunch of random stuff until you're comfortable with the core experience or you simply have to adjust or disable something that bugs you

- just using Emacs, and not customizing the crap out of it, ditto

If you haven't gone through the Emacs tutorial, it's how I learned it (at 300 baud, uphill both ways and in the snow -- not kidding about the 300 baud thing, though).

jimhefferon
Forgive the noise, but I second this. I haven't committed a hundred key combinations to memory. I find that knowing the twenty things I need to know (which are different for everyone), and having another twenty in my back pocket for once or twice a year has lasted me since 1992, and left me very satisfied indeed with emacs.
downerending
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)
philsnow
> 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.

If you're talking about production hosts, they shouldn't really have vanilla emacs installed either. Not having your creature comforts present on production machines is a feature, like the red shell prompt / terminal background some people use, a reminder to get you to think twice and try to not do things directly in production. If you really must, just use TRAMP, it's amazing.

If, on the other hand, you're talking about using somebody else's laptop to do anything, that doesn't make sense to optimize for, at least in my experience. I prefer not to even touch other peoples' laptops/keyboards.

downerending
I'm fine with not installing emacs, as long as no one ever asks me to fix their crap on those hosts. In practice, their stuff will always break, and they always will ask me to fix it. Production hosts should never be neutered. At a bare minimum, emacs-nox, strace, nmap, tcpdump, lsof. No exceptions.

Tramp is great, but not all such hosts are reachable that way.

> I prefer not to even touch other peoples' laptops/keyboards.

Me too, but that's why they call it work.

mbrock
Hopefully the Emacs is also configured to not leave tilde backup files everywhere!
User23
> 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.

I wonder if I'm weird, but I use a highly customized Emacs on my dev machine, but if I have to ssh into a host and edit something I just use vi there. The correct answer to vi or emacs has always been "both" for me.

kqr
I'm the same way, and I don't see why that would be so controversial. Vi(m) clearly has the better defaults, but Emacs is the better platform. (Then again, I'm the person who occasionally also uses ed just to keep it fresh in my memory, so there's that.)
regularfry
They're just optimised for different jobs. Vim for line-based editing, emacs for nested. It just so happens that editing config files on remote hosts tends to be line-based, while editing code locally involves editing nested structures. I'll happily use both on the same machine though.
fantispug
I'm the same; I use evil-mode in emacs and find the friction of switching between them small.
kbp
You can also ssh in via Emacs with Tramp, and use your highly customised Emacs to edit remotely.
shermanmccoy
Linux kernel developers would not want to use the third option on your list.
downerending
magit? Why not?
shermanmccoy
Some coding styles insist on tabs. I was referring to the third line of your configuration as quoted below.

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

dizzystar
for trailing whitespace:

(add-hook 'before-save-hook 'delete-trailing-whitespace)

This deletes all whitespace when you save a buffer.

h91wka
There is another positive side effect of limiting customization to reasonable levels. Default Emacs shortcuts are hidden everywhere. Most importantly, bash understands them, as well as many other REPLs (erlang, ghci, julia, ...). Developing muscle memory for the default Emacs allows one to use many tools much more efficiently.
zozbot234
Default Emacs shortcuts are bad for RSI. Even the original author of Emacs has had to cut down pretty dramatically on their coding activity, due to getting "Emacs pinky" and other RSI problems.
alexhutcheson
Mapping Caps Lock to be "Control" helps a lot with this. Reaching down to the bottom row for Control all the time is terrible and should definitely be avoided. Using Alt as Meta has been less of an issue for me since I can easily hit it with my thumb without moving too much.

evil is also great, and it might actually be the most popular option for new users at this point, thanks to Spacemacs and Doom.

__d
Second this: the key to the left of 'A' (for QWERTY) should be control for regular Emacs use.
donio
That's true for traditional keyboards and layouts. A keyboard with a thumb cluster that puts ctrl and meta under your thumbs makes all the difference.
smitty1e
I had to go to Spacemacs[1] for a few reasons:

- Using the spacebar to invoke functionality is a massive physical boon to usage. Stock emacs wrecks me from fingers to neck for an real amounts of usage. This is a purely subjective weakness.

- Spacemacs vi emulation. I drank the modal Kook-aid. Especially if one has to SSH into headless instances in the cloud. vi is part of the POSIX standard, so you know it's there and it's robust.

- Spacemacs engineering. Great package integration in the form of layers.

[1] https://www.spacemacs.org/

kalium_xyz
You can also just run evil mode for the vi emulation (its what spacemacs does), spacemacs is the best emacs IDE though IMHO.
weaksauce
you definitely can use evil mode but you will find a lot of edge cases where you have to configure something in some modes to behave sanely whereas with spacemacs they have usually done all that legwork of anything you want to use.
kalium_xyz
You also have doom which is just evil and not space centric AFAIK
smitty1e
Doom has good reviews AFAICT
shanavasm
I switched to doom from spacemacs and quite happy with it. Lot more easier to tweak that spacemacs.
weaksauce
i'm a large fan of space as a leader key even coming from vim so spacemacs felt like a natural extension. but yeah doom works for many people
banachtarski
My experience with Spacemacs was the complete opposite. There's a ton of inconsistency with the quality of the provided layers which is why YMMV when using it. The C++ layers up till last year was an utter disaster and I don't know if it's been fixed since.

The WORST thing about spacemacs though is their absolutely broken release process. The master branch rarely upgrades with fixes applied to the develop branch, and the tacit recommendation is just to run "on the bleeding edge." I have no idea why spacemacs users tolerate this, but my productivity has since improved after ditching it.

mijoharas
I run the develop branch and I can't really remember any significant bugs I've had.

I can kinda agree the C++ layer was definitely a bit of a pain, but I had general pain setting up a good workflow for C++ in emacs with the project I was working on (most of the emacs packages assumed a different layout, so couldn't understand my CMakeLists to generate the files it would need to look at for smart completion).

Overall, I quite like spacemacs, I used to hack on it a bit to make it suit my needs better, but now I rarely have anything I need to do it "just works" now.

I particularly appreciate that almost any language I want to use, I can just download a layer (I think it often prompts you to install one when you open the file automatically!) and a lot of the common across languages editor functions you want have similar keybindings, and the `which-key` popup will tell you anything you're missing. It makes a very short ramp up to being productive in your editor for a new language.

banachtarski
I'll be honest, my experience since has been that VSCode is... just better? I've been using vim/emacs for over 20 years now so it's a tough pill to swallow, but after trying out VSCode, I have to say that making it easy to program extensions with async functionality from the get-go was the right way to go. I think no combination of rtags, cquery, clangd, lsp, etc in Emacs/Vim/Neovim can approach the performance and quality of VSCode's C++ dev experience. And I say that having honestly tried every permutation of the above for many hours across many weeks.
alexeiz
I considered Spacemacs, because I used Vim extensively in the past (and still use it for some tasks), but I felt that Vim emulation in Emacs would only hinder my understanding of Emacs and steepen the learning curve. So I ended up incorporating useful bits and pieces from Spacemacs into my .emacs config, but stayed with native Emacs key bindings. I'm comfortable with my choice, but please change my mind if you feel like it.
squirrelmaker
Was it an acoustic modem? Just adds to the joy.
kabdib
Yup, a Novation Cat. I still have it, not that it's useful other than as a conversation piece.
xemdetia
I started this way and my next step was taking advantage of the current package manager. The fact you can inject new functionality so quickly made me really fall in love with emacs. Adding additional programming modes/file format modes without any headaches has been a boon to my usage of Emacs. I'm rarely tuning settings in elisp anymore and instead just adding a feature so the file has colourization and tab stops working properly. If I do actually want to customize something since customize-mode works well enough now I can usually find the modest setting I do want to change without much hassle.
boulos
What’s emacs --version say for you? My main complaint from using a Mac laptop for so long is that I often had to download some .el packages, that are basically unnecessary with more recent emacs updates. Other than that, I’ve also got a fairly simple .emacs file modulo a few project specific “let me make this a macro for this terrible manual process I need to do”.
alexhutcheson
FYI - the Emacs binary that's bundled with pre-Catalina versions of macOS (as /usr/bin/emacs) is 22.1, which is an ancient version from 2007. Apple kept that version because it's the last one that was released as GPLv2, and they've avoided bundling anything that's licensed GPLv3. This is the same reason that macOS includes an ancient version of Bash, and why they're switching to zsh as the default login shell.

Because it's so old, no one bothers to maintain compatibility with it anymore, and almost all modern elisp will break in some way if it's loaded in 22.1. Somewhat fortunately, it seems like Apple has removed this emacs binary from Catalina, so it won't be an issue on future versions of macOS.

To get a modern Emacs: https://emacsformacosx.com/ has binary builds of the official Emacs releases, with some additional scripts that let you launch it from Launchpad, etc.

dhosek
I'm in this school of emacs usage. I use Aquamacs on my Mac and while I've been using Emacs for almost as long as kabdib, I've barely scratched the surface of what Emacs can do. For me, the biggest thing that'll get me to drop out of IntelliJ (I was so happy to learn that there were Emacs keybindings hidden in one of IntelliJ's Mac keymaps) and into Emacs is to do ctrl-x(...ctrl-x) to record a macro, then ctrl-x NUMBER ctrl-x e (I'm hoping I'm translating muscle memory correctly) to do a repeated complex edit on a block of text. It's always fun to see junior devs (and occasional seniors) watch me do this and ask, How did you DO that?
kabdib
It's fun to see someone's jaw drop when you show them what you can do with a keyboard macro, some regular expressions and a little shell integration.

More than simple fun; I've saved people from hours and sometimes days of drudgery with just a few minutes of mucking about in Emacs. Teaching someone simple automation is pretty rewarding. Even if they are not technically capable of repeating your solution, at least they go away with a problem solved AND the knowledge that there are usually better options available than drudgery.

acomjean
I work the same way. Drop out of phpStorm or inteliJ into emacs to do some Marco recording. I tend to use f3 to record and f4 to run said macro.

That and white space mode for examining files..

scns
You can use Vim style macros in Intellij with the Vim plugin
drfuchs
My advice (and experience) is exactly the same as kabdib's (though his .emacs file is longer, and his baud rate lower, than mine). Literally the only advanced feature I use is Keyboard Macros (as dhosek mentions), but just that one feature is so useful, every other editor I've tried feels hobbled (even vi, which I used professionally for years). And no, multiple IPs doesn't do the trick at all. On the other hand, my pinky hurts.
jwr
This advice is fine for the first year or so, but afterwards I would start trying out various packages and customizations. There are packages that can make your experience much better (projectile, swiper, ace-window, ace-jump, move-border, eyebrowse, winner, color-identifier-mode, off the top of my init.el).

And, of course, if you do any programming at all, you should install magit immediately. It is the best git experience anywhere, on any platform, period. It is an unbelievable productivity booster, and people who haven't used it do not even appreciate what it can do (ever wanted to quickly apply a single diff from one of your stashes to your current code tree? it's two keystrokes).

Approach emacs like you would a musical instrument: you are not expected to play the piano on your first day, and the first year will require some patience and training, but eventually you'll start playing those sonatas.

[context: my Emacs init file has lines that are 27 years old]

b3n
In case you weren't aware, winner-mode is now part of Emacs, and as far as I can tell the Emacs 27 tab-bar-mode makes eyebrowse redundant. For me project.el that ships with Emacs is enough for my project needs.
jwr
Hmm. Do you mean that tab-bar-mode lets me have a full-screen Emacs (no UI elements whatsoever, as one does) and switch between window configs like if they were workspaces (which is what eyebrowse does)?

If so, I might want to try it.

b3n
Yes exactly, by default it has a tab-bar UI element, but you just have to set tab-bar-show to nil and you can use it to switch between window configs without the UI.
cjauvin
Typical Emacs user experience: sees a list of packages some other user likes, picks one with a name he finds intriguing (in my case eyebrowse), checks it, finds it cool, adopts it (possibly for a long time).
jwr
I've done this so many times. This is why I name-drop packages :-)
sufyanadam
Emacs is very easy to learn. Just as you learn the key combinations for video games, learning key combinations for emacs is really easy. Here are some steps to help you:

1. Go through the Emacs Tutorial. Just start emacs, put the cursor on the text 'Emacs Tutorial' and hit enter. It will only take 30 mins max.

2. Go through the first chapter in the Practical Common Lisp book here: http://gigamonkeys.com/book/lather-rinse-repeat-a-tour-of-th...

3. By now you are comfortable navigating around and editing text, opening files, running emacs commands with M-x etc... so you can now install packages for syntax highlighting for your language etc... via M-x package-install <enter> -> search for your language (usually LANGUAGE-mode), and install it.

4. Use emacs to edit all your files for at least 1 day.

5. Use emacs keybindings to navigate around in other apps if you're on Mac or Linux, those are standard keybindings that work everywhere in Terminal, bash, Textedit, Chrome, etc...

6. Learn how to use vim, download a vim cheatsheet and have it handy for reference, edit some files in vim (git commit messages will also do).

7. Install evil-mode and edit your .emacs.d/init.el file to bind a key to toggle evil-mode on/off

8. In maybe one day max, you're very comfortable in emacs now, and may be well on your way to writing your own extension functions. You're pretty much an emacs expert by now, in only 2 days max!

9. Try out different emacs configs. You can try mine out here: https://github.com/sufyanadam/.emacs.d it's setup for all major languages, Ruby, Python, React, JSX, etc... It also has some soundboard keys bound, try C-c-n-m when you want to greet someone new but don't want to be interrupted (you have to have mplayer installed on your system for it to work).

AnonC
Thanks so much for the detailed instructions and the focus on the basics and getting by step by step. It’s very comforting to read this, and it removes an inherent fear that learning to use Emacs may be way too complex.
neonscribe
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.
m463
I agree with everything you've said. I used to use Xquarts and xemacs but then that became available for a quick download.

I will mention cmd-c / cmd-w is still an anomaly. I sometimes capitalize stuff or close windows.

crispinb
Guidance here seems to fall into 2 camps - either (1) start vanilla or (2) with one of the currently favoured packagings (Doom, Spacemacs etc).

I'd say it depends on what your aim is: (1) would be the way to go if you primarily want to get fluent with emacs, or are content to use tools you already know for other work, and learn plain emacs gradually in the background. (2) would be best if you want to get productive quickly using emacs for real work, at the risk of a more occluded understanding of emacs per se.

I'd put in a word for Prelude (https://github.com/bbatsov/prelude) as a possible compromise, making emacs immediately usable but without putting many layers between you and it. Some might consider it a little old-fashioned however (no use-package etc).

I've used vanilla emacs on and off for many years for quick edits, but only recently for actual programming (using Prelude, and prompted by learning Clojure). It's taking over my computing lifestyle. I've laughed in the past at people using it for email, but found myself using mu4e lately. Scary.

NateEag
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.

smitty1e
Spacemacs is getting decent press here. How recently have you tried it?
freshhawk
I recently switched form spacemacs to my own config that works in a similar way.

I'm committed to modal editing and vim keybindings already, so spacemacs introduced me to emacs and got me to convert, but it is a 90% for everyone solution. It adds tons of stuff that mostly works, stuff which you specifically mostly don't need.

It mostly works, but coming from vim spacemacs is a big black box for the most part. I think it is a fantastic first step if you need to get something mostly working.

Going through and building up my own .emacs with the parts I wanted was the way I finally learned to grok emacs for real. It took that step to actually be able to understand what's happening when something unexpected happens. I also discovered a lot of alternatives to the spacemacs packages, well known by real emacs users, that I much prefer to the choices made by the spacemacs team.

NateEag
I object to Spacemacs not on the grounds that it works poorly, but on the grounds that if you throw all that into your config at once you will almost certainly have no idea what's causing problems or how to debug them.

Once you have a decent idea how the parts fit together, you don't really need Spacemacs, IMO.

I think the last time I tinkered with it at all was about a year and a half ago?

fiddlerwoaroof
I’ve used spacemacs before and have coworkers that uses it and, I’ve never found it pleasant to use. Unlike plain-evil-mode, it changes too many of the default emacs keybindings and it’s easier to build up a nice config (I.e. I ported my vimrc to emacs in a couple afternoons just by porting the keybindings and finding packages to replace my vim customizations) than it is to pare away unwanted features from spacemacs
lliamander
Spacemacs shows you what Emacs can be, but adds a lot of complexity that most people don't need.

I am currently a spacemacs user (holy mode, ya dirty heathens) and I like a lot of the built in functionality. However, I think that I will eventually build up my own config from vanilla.

smitty1e
The joy of emacs is that you really can configure it down to a gnat's booty.
nickjj
Back when I was playing around with Emacs I found Protesilaos Stavrou's videos to be quite good for getting a feel on how to accomplish specific things with Emacs.

They are at: https://www.youtube.com/channel/UC0uTPqBCFIpZxlz_Lv1tk_g/vid...

Most of the videos are focused on practical tasks you would want to do. It's one of the few really good Emacs focused channels IMO.

petr_tik
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
   - <optional> 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?

AnonC
OP here, so I’m completely useless for this. It sounds wonderful. Whenever you get this done, please do a Show HN or Tell HN on this.
petr_tik
hey, it will be interesting to see how you would tackle the problem as well to compare emacs novices to proficient users.
klibertp
I would be. You're not making it very easy to contact you - I don't have a Twitter account, and I couldn't find your email either here or on github, or on your page/blog. If you happen to see this comment (I'll add another with some thoughts on the matter), please shoot me an email (in my profile).
klibertp
In general, I avoid coding contests, especially if they focus on speed. This idea, however, caught my attention as something I'd like to both participate in, and obviously, to see the results. I'm a reasonably proficient Emacs user, and my config is (just checked) just shy of 5k loc mark. I would love to see if all the hours I put into writing that code make any difference.

I'll have more comments later, but the first two, slightly related to each other, would be:

1. Are you sure using just one language for the code is a good idea? It's going to instantly turn off large segments of people who would otherwise like to contribute - no matter which language you choose. Further, "the most popular language" may not even be appropriate: there's probably less Java, C#, and C++ programmers who use Emacs compared to the general population. I think the first step here should be a poll to see which languages are actually popular among Emacsers. Once we have the list, we can prepare a couple of codebases using the top 5 entries (for example.) I think I can contribute here - I don't think there'll be a language I'm unfamiliar with on the list. I'm also reasonably confident that, in case the improbable happened, I'll be able to learn that language in a few days. (Assuming there are docs available and so on, the usual disclaimers :))

2. Another consideration: how much time would participants have to prepare? I believe this is crucial. In my case, I have a bunch of "first-class" lang configurations, for the ones I spent the most time with, and "the rest," with configs just barely above bare-bones. If you give me a month, I guarantee I'll have all the possible tools you could use with the lang prepared, and I'll have quite a few hours of practicing their usage. If I had to go for it right now, and the implementation language happened to be outside of ~10-15 languages I use regularly or used extensively in the past - I don't think I'd be up for it.

> Starts a fresh emacs instance

Why a fresh one? Do you want to measure startup time (and later, performance in general)? But then people on the latest and greatest would have an advantage over someone working on a netbook.

> a emacs lisp script

I wonder if this wouldn't be better handled by an external tool. I don't know which, but it might be worth considering.

> logging keypresses/function calls might feel intrusive

You don't need keypresses - commands and functions would be quite enough. To be honest, I'd prefer a short chat with a participant afterward, maybe coupled viewing the replay at 10x the speed. What is valuable, I think, is the thought process behind the chains of commands, and "decompiling" those out of the "assembler" (key presses) of people's minds might prove quite hard.

That's it for now, I'll be happy to talk more about the idea, though I think we should take the conversation off the HN. My email is in my profile :)

petr_tik
Hey, great to see some interest and thanks for the ideas. I am going to keep the conversation going here instead of a private email thread, in case anyone else shows interest in this. I am also thinking about refining the design and asking for more participants on r/emacs + r/spacemacs or even language-specific subs.

I remember checking the thread several hours after posting my comment and assumed that it was so offtopic people didn't engage, hence the delayed reply.

> Are you sure using just one language for the code is a good idea?

The more languages the better, I was only assuming that I would be preparing the codebase myself, hence wanted to maximise ROI by choosing a popular language that I can write.

Adding more languages would be great, however, we would need to keep the code + tests + failures as consistent as possible i.e. no language-specific test failures due to multi-threading unsafety of C++, which Python's GIL prevents. Also I am not sure how useful cross-language comparisons are.

> how much time would participants have to prepare?

Prepare what? Ideally nothing in their language + emacs setup. The whole point is to learn about people's natural emacs workflow and what tricks they use when in the state of flow. I think each participant should only do it once in their "first-class" language, otherwise participants won't enter flow. That way, we control for no previous familiarity with the problem and get the best emacs knowledge and maybe even some elisp snippets others can follow.

To borrow a sports metaphor - I am sure that Tiger Woods can play a decent game of tennis, I would rather get tips from him to improve my golf swing.

> Starts a fresh emacs instance

That was a suggestion born from my workflow that minimises the risk of other buffers getting in the way of the test and preventing users' from leaking personal data during the screen recording.

> commands and functions would be quite enough

Yes and no. Some of Mike Zamansky's youtube videos have an on-screen feed of keypresses, which is interesting to watch for evil-vimlike navigation practices. I cannot promise I will be good at analysing a stream of keypresses and extracting meaningful analyses though, so commands and functions is what I can promise to analyse.

> I'd prefer a short chat with a participant afterward, maybe coupled viewing the replay at 10x the speed.

A chat is a great idea, however, if we manage to get a decent number of participants (ideally 40+ for each language for meaningful stats), my availability for a sync chat will become the bottleneck of the experiment.

I am thinking about replacing it with an async Q&A that the participant can add after completiion.

Torwald
I've found the Emacs Wiki always solidly maintained: https://www.emacswiki.org/emacs/SiteMap

S. Chua's blog is the best "zine" I think: https://sachachua.com/blog/

To avoid "but vi/vim and the shell…" which is a sort of "mental flu" every Emacser has to go through at least once in his life, understand this:

"the UI paradigm of Emacs" is also called a roguelike interface by ESR, vi's too: "In Chapter 11 we described the effect of the absence of standard arrow keys on early roguelike programs; vi was one of these. " http://www.catb.org/esr/writings/taoup/html/ch13s03.html

zeppelin101
I would honestly just start out with either Spacemacs or Doom Emacs. There is a lot of information on these 'distributions' and many YouTube videos, as well. These 'distros' will allow you to quickly get a feel for the power of Emacs, because they contain sane defaults that will enable you to get a quick feel of what Emacs is capable of. After doing this, you might decide to scrap them and start with a default Emacs installation that you slowly build up. But that is a huge investment of time and you should at least try these popular alternatives before you go into the crazy time sink of 'rolling your own' system. I realize that many purists might take issue with this suggestion, but it's what worked for me.