Mastering Emacs | Hacker News Reader

Mastering Emacs

masteringemacs.org

225 pointsamatheus99 comments

I followed this blog for a while and loved it! Strongly recommended for Emacs beginners.

Also, one thing beginners miss is how great it is to use an existing configuration to learn. I've personally used @bodil's config from here[1], it's pretty comprehensive and awesome. If you are a beginner though, you should totally start with @bbatsov's Emacs Prelude[2].

[1] https://github.com/bodil/emacs.d

[2] https://github.com/bbatsov/prelude

I went throught the hassle of not doing what you recommended, unaware, and it is funny how often you look for stuff to simplify Emacs usage and you find bbatsov.

New users who plan to configure and extend Emacs thoroughly might not benefit from using another person's configuration because they will end up reconfiguring that configuration, which I think is more difficult than configuring vanilla Emacs.

During the first weekend that I started using Emacs, I ended up writing hundreds of lines of Emacs Lisp to optimize Emacs for my usage. I had never written Lisp before, and I think using another person's configuration would have hindered my progress.

But I think that reading other people's configurations can be super helpful.

Phil Hagelberg, the creator of Emacs Starter Kit, seems to have arrived at the same conclusion that I have:

https://github.com/technomancy/emacs-starter-kit#history

If you're on OSX and want a good Emacs, go to https://github.com/railwaycat/emacs-mac-port and read the installation instructions under the Homebrew section. It follows the official Emacs repo pretty closely, but has useful OSX additions (smooth scrolling, gesture support [font size e.g] and more).

That git repo claims to be retired.

I get my emacs from here http://emacsformacosx.com

You misunderstand.

The repo you're referring to is Railwaycat's mirror of Yamamoto Mitsuharu's codebase. (which previously was only available via ftp and tarballs.)

Yamamoto has recently migrated to git and hosts a repo at Chiba U, the address is: http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

HOWEVER. Railwaycat does still maintain the Homebrew tap and formula for installing Emacs Mac Port

Here: https://github.com/railwaycat/homebrew-emacsmacport

A simple install via:

   brew tap railwaycat/emacsmacport
   brew update
   brew install emacs-mac

And you have a far superior Emacs for OSX than that built by emacsformacosx.com.

Once built, you can (without any problems) move the Emacs.app into your /Applications/ folder.

Don't do yourself a disservice, install Emacs Mac Port now.

So what is the benefit compared to the emacs port 'emacs'?

I found a full listing here: https://github.com/railwaycat/emacs-mac-port/blob/master/REA...

Thanks! Most of it was meh, but some sounds really good. The homebrew version provides hdr gfx but not all of this.

It's easy to misunderstand because it's not clear at all what is and isn't mirrored.

I'm on OS X, but I just installed GNU Emacs from source and run it in a terminal window. Never really understood GUI versions of Emacs -- they seem to defeat the purpose of Emacs.

Oddly, I find the opposite to be true, although I can't really think of a good way to justify why.

I have a GUI emacs-server running that I can open buffers from via emacsclient for "serious editing", but I often end up using vim for quick edits rather than bother with emacs[client] and context-switching.

I imagine it might be different if I could get used to running my shells from inside emacs with eshell or ansi-term, but have never had any success getting them to work right and be usable.

Actually, one reason for preferring the GUI does stand out - quite a bit more freedom in key-bindings, especiallly with ns-cmd-modifier and friends, and some C- bindings that are otherwise impractical in console mode (at least to my knowledge)

Since around 1999, my development workflow has been an IRC client, Emacs and various shells running inside a screen session. So it's not really context-switching for me -- Emacs is always live and running in there, so when I need to write or edit something, I just use it.

I would personally recommend using vim bindings in emacs, as they are (in my opinion) easier to make sense of and more intuitive. However, I'm sure this book is a great resource for all the other stuff and it seems very well put-together.

Evil user concurring.

spacemacs (includes evil) plug: https://github.com/syl20bnr/spacemacs

Really great.

Yep, that's what I use as well!

I switched to using Spacemacs from vim a couple months ago. I find it's a huge boost to my productivity; letting me use vim modes/hotkeys that I'm used to, and adding the handy features that emacs and plugins can provide.

HN Discussion with a LOT of good comments regarding Spacemacs [0]

[0] https://news.ycombinator.com/item?id=9394144

Spacemacs is absolutely amazing. I've done the rounds with emacs - trying it vanilla and rolling my own config, or using the various pre-made configuration packages (prelude, emacs-live, starter-kit, etc), sometimes with evil, sometimes without, and nothing has ever come close to what they've pulled off with spacemacs.

Learning some basic emacs bindings before using vim bindings is still valuable to me. Sometimes I have to use emacs bindings to do things.

When considering a tool with which one will work for many hours a day and many days a month over the course of years, for some people it makes sense to use expressive power rather than initial ease of use as the primary criterion for choosing among alternative sets of bindings. In the case of a tool like Emacs, the user is always likely to encounter new alternative work flows or to invent them theirself. This is what Emacs offers as an alternative value to Vim's Unix philosophy based idea of doing one thing and only one thing well.

There's nothing wrong with Vim, and nothing implicitly wrong with using Vim shortcuts in Emacs so long as one is aware of its Fortran in any language style limitations.

It isn't really about ease of learning - vim key bindings are just more internally consistent than Emacs ones. Even though I am a die-hard Emacs user, I like vim approach to keybindings better - because they're made to form a language of sorts.

Agreed. I'm a 20+ year emacs user. A couple of years ago I switched to using the VI bindings (evil). It really is the best of both worlds. I was using VI regularly before the switch -- it was available on servers and co-workers machines, and emacs generally wasn't. (Well, maybe it was on some, but the customizations definitely weren't). Now I have much lower switching costs, gain the quick access of VI bindings, and the huge number of emacs plugins. win-win-win.

Intuitiveness is subjective. Take cursor movement for example. I understand now h,j,k,l is a remnant from historic keyboards, but when I started learning vim, I couldn't fathom why 'h' moves a cursor to left and 'l' to the right, though I got used to it eventually. The emacs 'C-f' for forward and 'C-b' for backward were definitely more intuitive. Of course, depending on the mode, some emacs commands can be cryptic and leave you with a painful pinky, but they were definitely more intuitive to me.

hjkl is QWERTY-centric, and would be totally nonsensical to a user of a different keyboard layout, like Dvorak.

C-f, C-b are English-centric, and would be totally nonsensical to a user of a different language.

Intuitive is hard.

Hmm, maybe someone should invent keys with arrows on them! :P

That just sounds silly.

If you already know vi then keeping them as you move over to Emacs makes sense. Otherwise I'd recommend not doing this, as vi keybindings are an airbrake for productivity.

Key bindings are totally a matter of personal preferences. I like Emacs-style bindings better. The only thing I think vi in my opinion does better is copying and deleting lines (yy, dd, p), which in Emacs is not so simple for such a common operation.

ctrl-k ctrl-y ?

Not quite the same. For instance, to duplicate a line in Emacs you have to go to the beginning of the line, kill it and then yank twice, and it doesn't even work always, particularly at the end of a buffer. In vi, it's just yyp. No corner cases.

I've been using emacs for a long time. When I duplicate a line I don't even know that I'm following the steps you mention, I just do it on autopilot.

What I like most about emacs though is that I rarely have to do repetitive tasks because I can write a bit of lisp code to do them instead.

Or you can go to the beginning of the line, press Control-space (set mark), press Control-e (end of line), then Meta-W (copy), and Control-y (paste).

Just to share experience, i've recorded Macro named dup-line and bind to `C-M-y`. And find it very handy :)

I must ask you regular evil users this: how do you go about interacting with things (such as a REPL) with evil? I'm coming from vim and evil mode is great, but it feels somewhat clumsy to have to keep switching to insert mode to use a repl,doing stuff, going back to normal mode, then switching back to my code and editing it.

i use viper mode but with different keybindings (the most commonly used movement keys are under or near the home row, layed out geometrically): https://github.com/bshanks/viperre

I've always been an emacs user but have only recently gotten serious about customizing it to replace other applications I normally use. If anyone has bought this and at least skimmed through I'd love to hear your thoughts before I drop $35.99 to see for myself.

If you want to start heavy customization you can start by looking at configurations in literate programming style, you will learn a lot of documented customs.

Here is an exemple : https://github.com/vdemeester/emacs-config

Also about the book someone on #emacs said it's mostly tips for beginners and about 14 more for intermediate users. I'll suggest you to read the website first and see if you like the author style/pov

Thanks for the info :) I did enjoy the posts I read on the site, but was hoping for more advanced material in the book, good to know. Browsing through that repository right now, awesome stuff, I'll have to look for more like this.

I've just bought and skimmed it. In my opinion it looks like a good introduction to emacs and its included packages for new users but it does not really discuss customization in detail. I really like the chapter "Theory of Movement" which discusses editing commands.

Thanks for the heads up. I really liked the blog posts I just read through but I think I'll avoid making a purchase in that case.

Swap your CTRL and caps lock keys. It will make it a lot easier to use.

No, swap your alt-gr and ctrl.

Put Ctrl on left Alt. And left Alt und right Alt (Alt-Gr). Then you are free to finally map Caps Lock to Escape. After that map left Ctrl such that left Ctrl+E/S/D/F is Up, Left, Down and Right.

I map esc to the key between left shift and Z. It doesn't exist on US keyboards, though. And I put backspace on caps-lock. What I don't understand is putting any kind of simultaneous combo key on caps-lock, since caps-lock + a is not really easy to press. It doesn't help that many keyboards have a bit of a gap between a and caps-lock (to help position the left hand and prevent accidental caps-locking?).

I guess this is if you use your pinky to hold down CTRL? I try to mostly use the knuckle below my pinky fingers[1] to hold down CTRL. This can be harder on certain keyboards, and I guess especially laptop keyboards. I think I learnt this from some kind of ErgoEmacs article/webpage.

I also use god-mode, and one of the tips is to swap ESC with CAPS-LOCK (ESC is used to toggle god-mode).

Nonetheless, I guess most of us can agree that CAPS-LOCK is in a too convenient position compared to its normal utility. :p

[1] I use my left hand to hold down CTRL when it's more comfortable to press the next key with my right hand (like in C-u), and vice versa.

Yes, that was from ErgoEmacs. Very nice info in there.

Nope, don't do that. Learn to proper touch-type instead. Use your palms to press the ctrl keys. See: http://ergoemacs.org/emacs/swap_CapsLock_Ctrl.html .

You can then use Ctrl+m instead of Enter at the command line, as well. Save both pinkies from the extra effort.

A keyboard with symmetrically placed C and M keys is another piece of Xah Lee's sound advice: http://ergoemacs.org/emacs/emacs_pinky.html

I've been using the MicroSoft Natural Ergonomic 4000 for several years and it has improved my touch for M and C. Recently, I've been applying that on my ThinkPad [chosen because of the symmetric layout] and am removing some additional bad habits related to left-C right-C.

I've seen these arguments before, but find them very unconvincing. I've no idea how I'm supposed to comfortably press ctrl with my palm, the issues with 'now hotkeys are in bad places' are resolved by just not having capslock at all (although I don't actually have any difficulty pressing anything either way), and the pinky load/awkwardness just doesn't seem that important to me, I don't think the keyboard is particularly well calibrated to use the pinkys appropriately anyway.

I'm happy for some people to find these things important and type differently, but what is the evidence that it is actively wrong to bind caps-lock as ctrl?

Edit: There are a lot of good points in these pages and I appreciate that the author has made many customisations in pursuit of an ideal layout, and the principle of sharing load between hands equally is a good one. It's just that I'm quite unconvinced that having capslock act as ctrl is a terrible thing, especially compared to many other changes that can be made even on a normal keyboard layout.

Using your palms to press the ctrl keys is only seriously possible on some curved keyboards. Everyone else, who prefers to touch keys with their fingers, like they were meant to, is going to do the sensible stuff and put the more frequently used modifier in the more easily-reachable place.

All this press-ctrl-with-your-palms fad is a problem solved in the wrong place.

And I have to say I dislike the tone of that page, too:

> Swapped but never had a problem [...] > Because you don't actually type that much.

Right.

> Using your palms to press the ctrl keys is only seriously possible on some curved keyboards.

It feels fine to me on my flat keyboard with low-profile keys.

I used to use my pinky to press ctrl. Then I briefly remapped to caps-lock, but that felt awkward to use together with the shift key (but I didn't use it enough to get truly used to it). Then I switched to using my palm, and then finally to using god-mode which means that I don't have to use modifier keys as much anymore (though I still use it sometimes, and I still press ctrl just as much in non-emacs applications like terminals and Firefox).

> All this press-ctrl-with-your-palms fad is a problem solved in the wrong place.

Total agreement from me, I consign this piece of advice to the same trash pile as !!NEVER USE ARROW KEYS!! ... cargo-culting nonsense.

Palm/ctrl won't work on most laptops, especially since nearly all of them have chiclet keys these days.. heck, more and more desktop keyboards do too.

Remapping capslock to ctrl on all my machines turned out to be one of the best things I have ever done. It helps me with far more than emacs.

Also, Ctrl+j works as 'enter' as well.

A decent subset of emacs keybindings work in anything that uses gnu readline or similar library (ctrl+a|b|f... etc).

If emacs expects 3 modifier keys, and emacs is wildly popular with programmers, then why hasn't someone made a keyboard with the windows key renamed and remapped to the missing meta key?

I do use that remapping with a Kinesis keyboard.

Meta is Alt.

Look up HHKB, that is what the best emacs users I know prefer to use.

you mean like this?

http://i.imgur.com/evUJkAv.jpg

I feel like if there was a "One True Emacs Keyboard", it would probably be something like http://mykeyboard.co.uk/microswitch/

If Mastering Emacs isn't the right book for your situation, you might consider purchasing a hardcopy of the Emacs Manual:

http://shop.fsf.org/category/books/

As a bonus, you'd be supporting the Free Software Foundation with your purchase.

I'm really enjoying using Cask to manage my Emacs packages:

https://cask.readthedocs.org/

You maintain a list of packages in a Cask file and run "cask" to automatically download and install them from a repository like MELPA. Like Gemfile or requirements.txt, but for Emacs.

I found this really reduced the number of elisp snippets I've had to write or grab from around the web. Most popular packages are on MELPA, and there's usually a more polished way to accomplish things I was hacking together myself.

I hadn't tried Magit before now, but on the suggestion of this blog I'm giving it a look through. Looks good so far. I also enjoy the style the blog is using: anyone know what backend the author is using?

One thing I hated about magit was that I couldn't stage multiple files with a region or similar. I'm currently on my phone for the rest of the evening so I won't have chance to check - if you notice this has arrived in your testing, do let me know!

I usually use shell emulator + company for dir/file autocomplete. This is the fastest I've got to staging individuals files or dirs, especially with projects that have a dir depth bigger than 1.

In magit-status-mode I'm able to stage files based on the region.

I can also expand them and highlight multiple chunks to stage just those chunks.

The are only two major things I don't know how to do with the current stable version of Magit (1.4). One is starting an interactive rebase. It can take you through the commits and let you edit the buffer, but I haven't figured out if it's possible to start an interactive rebase without using the "!" command line.

The other thing is checking out files in order to revert them, I'm sure there's a way but using "!" and pasting the file names in still seems fastest.

I've also been wondering if it's possible to write a command to manage the `--skip-worktree` status of files, showing which are currently skipped in magit-status-mode. That would be a useful thing for me to have.

I wrote this gist that adds the ability to add multiple files from dired to git

https://gist.github.com/justinhj/5945047

> stage multiple files with a region or similar

This feature has been available for some time, I believe. In magit-status, just select with region the files and then `s` to stage the highlighted files.

It's a little un-intuitive.

Adding git-gutter to the mix will allow staging / reverting at the hunk level.

I should probably note also that in Magit status, the user has to TAB the unstaged file to be able to do region or hunk level staging.

Ideally it would be possible to do it in the buffer in question as well.

Not even git-gutter has region style staging. Hopefully it will be implemented soon. I had a crack at it but time got away from me.

Thank you for this - git-gutter looks awesome. I wasn't aware of staging hunks too so I've learned about 2 things :)

There's a lot of power hidden away.

Interactive rebase/squash is tough to find... so here it is.

in Magit status, do l l (log, short-log)

Select the sha1/commit you want to begin squash/pick rebasing...

press E

off you go.

Is it weird that I wish somebody would make a terminal-ized version of newer editors like Atom/ST/Brackets?

How else can you screen/tmux your work? Terminals ftw.

If you're using emacs you can use M-x eshell to open a shell. Combined with tramp (which lets you open remote files via ssh: C-x C-f /ssh:you@otherhost:path/to/file) you can actually avoid using tmux/screen at all. Instead of managing screens in tmux and simultaneously buffers in emacs, you just need the emacs buffers.

What I was imagining is launching Emacs in a tmux session, doing your editing (at work, for example), detaching that session (but not closing it), going home and logging back into your work machine and reattaching that same editing session.

There are other client/server solutions than VT100 terminals. X11 being one of them. And you can run a remote Emacs server and connect to it via emacsclient without being constrained by several emulators as middlemen.

Plan 9's sam had a similar client/server switch, mostly because the programmers didn't really like a) character graphics and b) their host systems.

That's a good point. I've never written a client that is "multi-interface re-entrant" like that (I have used and enjoyed emacs-client). The nice thing about character cell terminals is that all the terminal handling falls out for free: I don't need to accommodate for anything (like tmux, or remote access (like ssh)), it Just Happens.

Worth considering (or modeling) how I'd write an emacs-client type of application though.

An older but still interesting book, just in case: http://www.amazon.com/Writing-GNU-Emacs-Extensions-Glickstei...

I bought it when it first came out, and it is still on my bookshelf. A decent book, as the Amazon reviews indicate, but not outstanding.He does cover a lot of ground, introducing emacs programming (and Lisp, in general). I did not find the "Comprehensive Example" chapter implementing a crossword puzzle mode as particularly helpful.

Everyone feels like other people do better negotiating car prices, and I feel the same way about "knowing" emacs. I have used it every day for over twenty years and people are still telling me "there are easier ways to do that in emacs."

Anything that large will have blind spot for a user. Even commiters might be surprised by some kind of idiom in elisp or in a particular mode. That syndrom can be found in languages. It would be of great value to document this side of things. Some spectrum of learning, showing how everybody travels through and that most people go through the same stages. Maybe how to not waste time or feel frustrated by that process.

ps: emacs should have 'didntknowthat...' as subtitle.

pps: I wish for an Emacs rewrite. As a scheme/lambdacalc enthusiast, I love pruning things out to a certain extent, and feel Emacs is too much a bazaar, and would love for it to fork a smaller core mammalian child. Something even more self-documenting [1] and with a stronger fp-ish flavour (when it's not absurd).

The goal, making it easier to learn and understand.

[1] a lot of knowledge about emacs is outside of it both in location (not in the manual) and form (videos, podcasts, static tutorials). This is influenced by the trend for interactive documents (B.Victor, Wolfram) and Notebook/Persistent repls (ipython,...).

it is also available as an ebook from oreilly: http://shop.oreilly.com/product/9781565922617.do

I really like this blog, it's great. Very engaging. Would recommend subscribing to it!

ps thanks for the downvote HN - classy :-)

I didn't downvote your post, but I can see why others might feel that it doesn't contribute to the conversation because basically the only possible responses are "Me too" and "You are wrong". Adding the complaint about the downvote would ordinarily get a downvote from me, but I'd already used my vote in search of justice.

Anyway, consider the downvotes editorial feedback and perhaps taking advantage of the opportunity to improve or remove what you have written.

My post is about what a great blog it is. I'm fine with my original mark. If anyone wants to remove computer points from me please fire away.

And what is your last comment about and how does The comment make HN or the internet better? There are lots of places where typical internet behavior is typically acceptable and often encouraged. HN, for better or worse, is not one of them. That means it can't meet everyone's expectations.

It's a community where the consensus is wherever the community decides. If you didn't speak your mind people like me would be the centre, if I didn't speak mine people like you would be the centre.

I'm not sure what you are trying to achieve. I've said my comment, I've re-iterated it. You have made two meta comments about HN that I have zero interest in. Create a new thread on HN meta and write about it.

Again: the author of the book has a great blog and I'd highly recommend subscribing to it.

Have a very positive, non-supercilious day.

That such comments lead to more comments of dubious value is something about which we appear to agree and have empirically supported. Hence, the reason people will down vote such comments,

This sort of "empty praise" is also commonly encountered in blog comments as spam, because it is so easily generated. I suppose others here have experienced the same.

I haven't read this, but from the contents it seems like you can learn everything there is in the book from the official Emacs GNU documentation:

https://www.gnu.org/software/emacs/manual/html_node/emacs/in...

While RTFM is technically a correct answer to any Emacs question, the reason for purchasing a secondary resource is that the author has presumably curated the documentation for a particular audience.

I agree that Emacs documentation is very good, and once I recently got in the habit of C-h'ing for answers rather than Google'ing I became more productive and can work more productively with the WiFi on my laptop off [not having the temptation of HN among the productivity enhancements]. But this doesn't change the fact that better explanations are possible and that a teacher is often better than a specification. Experts can contextualize a problem, and that has added value.

Wow, what a really mean-spirited comment, and it's the top one (at the time of writing.) -- did you consider what you said here before writing it? Let me propose a rewrite:-

'If you can't afford to buy this, the official emacs GNU documentation is great - [link]'

Instead you first admit you haven't read it, then imply, but in somewhat weasel words, that it doesn't offer anything beyond what the official documentation offers.

I'm a long-term emacs user and I can tell you that while the official docs cover a lot, they provide more of a reference than a guide, so a book like this is really worthwhile.

Keep in mind the author would have dedicated enormous amounts of time and effort to writing this, and technical book writing is very rarely a profitable enterprise.

I think we need a bit more kindness towards people's work (as well as _constructive_ criticism of course) - how do you think the author might feel reading this on such a prominent tech website? Imagine it was something you worked on for hundreds of hours, dismissed in the top comment, how would you feel? We're all humans, and empathy is already lacking enough in our industry, so think a little before posting next time.

Actually, good technical writing is among the most reliably lucrative genre of writing.

That might not be saying much, but how many people make money writing poetry or genre fiction?

Ha that's a good point ;) but once you factor in opportunity cost for developers, especially ones experienced enough to write a book, it's definitely not a great choice (likely negative.)

I don't know if buying a book is worth it compared to the manual/documentation. But nonetheless, Emacs is a very self-documented program.

http://emacswiki.org/emacs/SelfDocumentation

As a long time Emacs user, I would recommend using the real documentation too. Learn how to use the built in info and help, and study some of the elisp.

The author discussed this on reddit the other day. Supposedly the guide helps you get into that workflow.

http://www.reddit.com/r/emacs/comments/36zcny/im_pleased_to_...

Although I haven't read this book, I read its ToC. Apparently it seeks to introduce you to the Emacs way of doing things. And guess what? Near the end, it emphasizes how to use Emacs' self-documention: https://www.masteringemacs.org/book/look-inside/table-of-con...

I'm embarrassed to say how long I used Emacs knowing about C-h f -- but not noticing and using C-h i to read the full documentation from inside Emacs. I wish I'd appreciated that from the start.

At this point I've read the full Info doc at least once through, some sections multiple times. It's impressively good, especially for getting a crisper understanding of topics you only sort of understand. It's one of Emacs best features.

But I can totally see the value of a good introduction book, and wish I'd had one when I was starting out. So although I don't know how good this book is, I don't think a book is pointless.

Reply on news.ycombinator.com