Hacker News new | comments | show | ask | jobs | submit login
How to Learn Emacs: A Hand-drawn One-pager for Beginners (sachachua.com)
209 points by alexott 1440 days ago | hide | past | web | 165 comments | favorite

As I've moved to more polyglot programming (Java, Javascript, Node, Ruby) I've made a concerted effort to get back to Emacs after starting out there 10 years ago.

Using the same environment for all of my coding together with the tightly has been a massive increase in productivity for me. I've literally never been producing more on my side projects mainly due to this choice.

The reduced friction of using the same IDE on all of my different devices means that I can hit flow much faster, with the same shortcut keys, the same workflows, the same tools etc at my disposal regardless of what I'm building.

I prefer Emacs to VI mainly due to the tight shell integration. I'll always have a shell open where I'll be testing my code and running curl etc, keeping the feedback loop much tighter than it ever was in any IDE.

Picking up Emacs or VI is definetly worth the initial pain if you program in multiple languages.

I can recommend evil mode to occasional uses of vi things. Though I'm the crazy guy who tried to use only emacs (or emacs-alike tools, i.e. conkeror for web browsing) for a month, after reading Practical Vim I've found out some things in vim are rather neat, and I want to use them (text objects, mostly.) Evil does the trick neatly.

> polyglot programming

Over the years, I've used Perl, PHP, SQL, shell scripts, Python, Tcl, C, Erlang, HTML, Javascript, Java, Ruby, LaTeX, DocBook and other flavors of XML, nroff (man pages), CSS, and probably other stuff I'm forgetting. Emacs always comes through with pretty good support and a familiar environment, even if the particular language is a new one. I'm confident that it will continue to do so in the future.

Unless they're on a resource starved or crippled machine, most people are going to prefer using vim to vi -- though I have run in to people who stubbornly prefer the ultra minimalism of plain vi, even when they could run vim.

So, vim, not vi, is really what you should be comparing emacs to. Vim is far more feature rich than vi, and has plugins that allow shell integration. So shell integration is not a good enough reason to prefer emacs over vim, as vim has it too. Further, emacs' shell integration really isn't that great (contrary to many claims I've heard in the past). It's pretty buggy, with random screen corruption and many keys not working as expected.

That said, there some great reasons to prefer emacs over vim (and I say this as a vim user of about 20 years who's in the process of switching over to emacs).

The first reason is eLisp. I love Scheme and Common Lisp, and much prefer to have an editor that's scriptable in a Lisp dialect. Yes, here too vim isn't quite stuck with vimScript only. It is possible to script vim in other languages (like mzScheme/Racket, Python, Ruby, and Lua). But 99.9% of vim scripts are written in vimScript, for reasons that I guess at elsewhere.[0] There are maybe one or two vim scripts written in Python, but I've never seen one written in mzScheme or Racket (or Ruby or Lua, for that matter). So, practically speaking, the vim user is stuck with vimScript after all. That's not the case with emacs, where the entire community scripts in eLisp.

The second reason is the tight integration of many applications with emacs. You could read your email in emacs, browse the web through emacs, read RSS news feeds through emacs, etc. And when you do this, you bring the entire power of emacs to bear in customizing and interacting with these embedded applications. As a result, much of your environment becomes easily extensible and customizable through eLisp, and automating repetative or complex tasks that you perform in these applications becomes much easier as well. Yes, you might be able to do something similar in your standalone browser through Javascript, or maybe your standalone mail reader might be scriptable and extendable to a certain extent, in some language or other. But if you choose the standalone application path, you're going to wind up with a very fragmented ecosystem, programmed in a half dozen or more languages, and not very tightly integrated. With emacs, everything is tightly integrated and programmed/exteneded/controlled through eLisp.

The third reason is org-mode. Here again, vim is not completely without it, as it has some plugins inspired by org-mode. But from what I've heard, they're a far cry in capability from what org-mode offers in emacs. That said, I'm only starting to dip my toes in to org-mode in emacs, and have never tried the org-mode-like plugins in vim, so I'll stop with the comparisons here. But I will just quickly mention that I've heard of people switching to emacs just for org-mode, and after using org-mode a little, I can understand why.

The fourth reason is Guile. In the not-so-distant future, Guile will bring emacs scriptability to the next level. Many things that were painful or impossible to accomplish with emacs built on C and eLisp will be able to be accomplished with emacs built on Guile. (See here[1] for details) That said, eLisp is not going away, and is not going to be fully replaced by Guile.

The fifth reason is evil mode. Emacs can do a fair emulation of vim's core functionality. Evil mode can go a long way towards making a vim user comfortable in emacs -- and in letting emacs users edit more efficiently using vim-like keybindings. (There are probably vim plugins that try to do something similar for vim, but I doubt they do much beyond providing a handful of emacs-like movement keys.) With evil mode, you get the best of both worlds.

There are probably other good reasons to prefer emacs to vim. But those are the ones I can think of off the top of my head. There are also good reasons to prefer vim to emacs. I personally find that vim provides a more usable experience out of the box, without too much hacking. But I may be a bit biassed here. This is actually an area where both editors could stand a lot of improvement, as both do require some hacking around to get the editors to a reasonably usable state. Yes, you could do basic editing in both out of the box, but really not much more (unless you're a masochist, or RMS -- who supposedly prefers vanilla emacs).

There's also less to learn and tweak in vim (simply because it doesn't have a ton of applications that can be integrated in to it -- you are basically going to be learning and tweaking its editing capabilities only). So in that sense, learning and tweaking vim is easier than learning and tweaking emacs.. or at least you'll probably spend less time doing so. Emacs is a supermassive black hole of infinite customizability, while vim is more like a regular black hole of editing-oriented flexibility.

I'd continue making an exhaustive comparison of the two editors, but this is starting to get kind of long.. In sum, they are both great and powerful editors, and you would not go far wrong in choosing either. For me, the balance has tipped in emacs' favor, but I would not begrudge anyone for choosing vim.

Update: Yes, SLIME! How could I forget SLIME? SLIME was one of the first things that attracted me to emacs. Now I'm actually much more interested in programming Scheme than Common Lisp (at which SLIME is primarily aimed at). But emacs also supposedly has some nice REPL integration with Scheme as well, including via SLIME.[2][3] It also has parens mode, which makes editing sexp's so much easier than they would be on vim (to my knowledge). That said, vim also has some REPL integration plugins, like Nekthuth.[4] They're not nearly as powerful or well integrated as SLIME, however.

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

[1] - http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg006...

[2] - http://www.emacswiki.org/emacs-en/Scheme

[3] - http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-sc...

[4] - http://www.nekthuth.com/

This is one of the most thoughful comments I've read on vim and Emacs. I too have been using vim for about 20 years, and am just starting to learn more about Emacs. It is helpful, thoughtful comments like these from people who have actually used both editors that make leaning a whole new editor seem like a reasonable, non-religious proposition. SLIME helps too.

For me, the reason why I decided many years ago to give Emacs a try is the nice integration between Emacs and REPLs; it's really nice to be able to press `C-c C-l` (or something equivalent) and have the content of the file loaded into the currently running REPL. This makes experimentation and incremental development much more fun.

Command-T is written in Ruby, no? With natively compiled Ruby extension for performance. Is there something like that for Emacs, by the way? I couldn't find it, no matter how hard I searched.

It seems like vim+(screen|tmux) would be a more apt comparison than just vim by itself. You get copy/paste across multiple shells, into your editor, etc. If you take term output and just paste it into vim, manipulate it, then source the file, you pretty much get the only thing I felt was missing by using Vim instead of Emacs.

Not to mention that vi has been absent of every Linux or BSD distros for 20 years. Since the nineties, the vi command is always an "alias" to a vi clone like nvi or vim. Never real vi AFAIK.

Do you lose any of Emacs' advantages/capabilities/features when you run it in terminal mode (emacs -nw) instead of windowed?

Yes. You lose the ability to perform certain key chords (which happen to be default). Terminals do not distinguish between upper- and lower-case control keys, for example.

Thanks, but what you and hkolek are saying sounds contradictory. Are case-sensitive key chords critical, and losing them borks its workflow?

Bascially I want to give Emacs a shot, but using Evil-mode b/c I love Vim's modal edititing, but I also like working in terminals (I do a lot of remoting to cloud servers).

I guess I should just give it a shot and see how it goes.

Not to my knowledge. I always use Emacs in terminal mode even when I have a window system available and I have never encountered anything that would only work with a GUI. I think there are some extensions that work only with a GUI but that's not an inherent limitation of Emacs and there are usually a ton of alternatives.

Auctex mode gives you graphical previews of your LaTeX documents. That would be hard to do in a terminal.

Interestingly, I prefer vim to Emacs because of vim's tight shell integration. I feel like Emacs always try to reinvent the wheel, whereas vim plays much more nicely with the os shell. Just pipe arbitrary text through commands, outsource search to grep, building to make, etc. In fairness, I haven't learned Emacs yet, so maybe my impression of NIH is unfair.

And in most programs (especially vim) I'm only ever a C-z away from a shell I can use to test code, run curl, etc :)

It just makes more sense to me to host my text editor in my shell, not the other way around. But then, I guess Emacs isn't really a text editor so much as a development environment, complete with integrated shell.

Interesting that most of the comments so far (62) have been about the content rather than the form.

I rather like the form; simple, direct and 'human' through the use of hand drawn text & diagrams. The information density seems about right at one side of A4.

Does anyone else remember Donald Alcock's series of hand drawn books about programming languages a few decades ago?

That's awesome! I hadn't come across Donald Alcock's books before, and I'm glad you recommended them. I've just ordered a copy of Illustrating C. Looking forward to being inspired by it!

I liked the form of Alcock's books. I am not competent to comment on the quality of his instructions for learning a language like C (although I did finally work out pointers) as I am not a professional programmer. I did use his BASIC book with students.

I think you should do a review of Alcock's C book when you have read it.

Great "learn the terms" section. So many tutorials come with a huge up-front wall of text explaining every possible term you could ever come across, when all you want is to get to the useful stuff!

The approach I took in my own guide to learning Emacs[1] was to mention those terms (like "C-x", "buffer", "frame", etc.) as if the reader already knew them, but hyperlinked to a glossary.

The most important part of Sacha's diagram is the bottom left corner: "Learn how to learn more". Every Emacs expert will tell you about "C-h k" and "C-h f" etc, but few novices actually understand how much you should be using those self-documenting features. My guide focuses on this, for those with the patience to work through it. :-)

[1] http://david.rothlis.net/emacs/howtolearn.html

I've been using emacs for a couple of years now as my main editor, but I haven't gone past the 'casual' mode of usage - I haven't tinkered with the config file except for copy pasting stuff and never did try to create my own macros. I should try to incorporate that into my workflow very soon.

On a related note, Sacha's blog has been in my reading list since delving into 'serious' development mode six years ago. It also influenced me to try out emacs resulting to my love affair with it right now.

Be warned, you can get sucked in very easily :) Pretty soon, you're using org-mode to manage your life, then you hook up an XMPP client, start using Magit or Egg, have a shell open, and eventually it's your only app open, full screened:



> If you're a developer or sysad... learn VIM

I really don't understand this mindset. You don't want to install Emacs on a server? Fine, install mg, it'll do 90% of what I need. If you whine about a 170k binary when a modern vi is 2MB, by god I am not a violent man but I will throttle you with a CAT5 cable.

As a sysadmin, you have to be capable of quickly editing files no matter what or whose machine you're on.

This means that you often don't have the luxury of installing anything on the machine you find yourself on. You might find yourself on a small Linux-based router that only has busybox on it. This is the case for many resource-starved VPS' and other small Linux installs as well. Busybox comes with vi, but not with emacs (or even vim). If a sysadmin finds himself on one of these, he simply has to make do with what he has. He may not have the time, or an internet connection, or the authority to install anything at all. So familiarity with vi in these circumstances is essential.

On very few machines will the situation be reversed: with emacs or mg available and vi not (I have never run in to such a case). So a sysadmin has little incentive to learn or install emacs.

As for mg, even if you could install it, I'm really not sure what it would buy you over vanilla vi. In the kinds of resource-starved environments where you'd actually prefer mg over emacs, you wouldn't want to spend a lot of time editing anything. A quick in and out edit should really be all you could reasonably be expected to do in such a situation... and that could probably be done equally well with either mg or vi.

vi is part of POSIX (the UNIX standard):


emacs is not

So it's not surprising you find vi more places than emacs.

Tim O'Reilly wrote that ORA sold twice as many vi books as emacs. (http://oreilly.com/pub/a/oreilly/ask_tim/1999/unix_editor.ht...)

In 15 years as a sysadmin, I've never seen a machine that had emacs but not vi. :) Though I agree it's theoretically possible. In which case, knowing ed would get you going quickly. Knowing ed can speed up your work in vi, too, you can handle large amounts of text quickly using short powerful ed commands. (for example, write everything from the start of the file to the current line to file /tmp/save.txt: 1,.w /tmp/save.txt Or delete all lines that have a curly brace: g/{/d)

Peteris's excellent ed sheetsheet: http://www.catonmat.net/blog/ed-unix-text-editor-cheat-sheet...

What if you don't have the rights to install anything on the server and the sysadmin doesn't want to install Emacs there? (For good reasons.)

Vi(m) will be there.

> the sysadmin doesn't want to install Emacs there? (For good reasons.)

As I said, even if he doesn't want to install emacs (not that there's any actual, let alone good, reason to do so save being an asswipe) there is no reason not to install mg[0].

[0] unless you refuse to install any other editor than `ed` and `sed` on servers because you believe no file should ever have to be edited there. That's perfectly reasonable. But then I won't find myself having to edit a file on a server in the first place.

There is a good difference between a sysadmin's workstation and/or what I'll call "management servers" - those we use for our own tools and whatnot, and those that we keep up for production use, where uptime is critical and knowing exactly what is going on is paramount.

I use emacs... all the time. It's my favorite editor, bar none.

I use vi/vim every day, because it's always there.

It's not that no file should ever be edited there, but, especially in today's clustered world, it's good practice to keep your servers as minimal as possible.

It might sound silly, but keeping to principles and controlling as strictly as you can get away with the changes that go into your production servers is a good practice that tends to keep things working.

vi is handy because it's always there. Emacs is fine - but it only REALLY shines for me when I have my custom environment set up - for a quick edit, it's just a quick edit.

There's an actual and very good reason not to install emacs on servers. It has had a persistent bug where on terminal hangup it occasionally won't stop but will keep running and rapidly leaks memory, until the OOM killer is triggered and causes random havoc. I'm a emacs user, and so are all the technical people in our company. Doesn't matter - installing it on production servers would still be unacceptable.

As a dedicated emacs user, I would like to know more about this bug. Is there a bug report or mailing list discussion you could point me to? thanks.

Not that I know of. (I've seen it happen on Ubuntu 10.04 / Lucid, Debian 6 / Squeeze, Centos 5, RHEL 6, and with no .emacs).

I can maybe - maybe - understand not putting emacs on a low resource machine (something like a WRT54G, etc). This is coming from someone who loves emacs so much that I was considering posting a comment along the lines of "fire the non-emacs-installing sysadmin, or I quit."

OK, but then you'd uninstall vi before you'd refuse to install mg.

Using mg misses the point of using Emacs. I use Emacs because I can customize it deeply and extend it into a near IDE and universal interface. mg is just a text editor with Emacs-like bindings which is not worth much to me.

Also, the 'vi' on most unix/unix-like systems aside from Linux these days is nvi, not vim. which is about 200K, not 2G.

> Using mg misses the point of using Emacs.

And you completely miss the point of mg:

> mg is intended to be a small, fast, and portable editor for people who can't (or don't want to) run emacs for one reason or another, or are not familiar with the vi(1) editor. It is compatible with emacs because there shouldn't be any reason to learn more editor types than emacs or vi(1).

> mg is just a text editor with Emacs-like bindings which is not worth much to me.

It is of worth to me when I need to edit files on an other machine than my own, I've got the basic navigation and edition bindings embedded in my nervous system (even more so as they're also the edition shortcuts of standard Cocoa controls)

> Also, the 'vi' on most unix/unix-like systems aside from Linux these days is nvi, not vim. which is about 200K, not 2G.

I said 2M not 2G. And OSX uses vim as well[0], so most active VIs are probably vim not nvi. But even assuming it's nvi you have, that merely makes it as small as mg, still no justification to not have mg.

[0] I'm not sure any non-BSD unix-like uses nvi actually, MINIX has switched to elvis and OpenSolaris looks like it uses vim.

> Vi(m) will be there.

It’s not on my servers…ed, on the other hand, will be readily available for everyone :)

Well, there's always Tramp :-)


You can use SSH + Tramp and not even open a shell on the server.

Edit everything from the comforts of your desktop!

You don't want to install Emacs on a server? Who cares, I use TRAMP anyway.

TRAMP is great if you're editing from an account where you have access to emacs.

But what do you do when you're in front of a machine that doesn't yet have a network connection?

Or what if you're onsite with a client who doesn't have emacs installed and doesn't want you connecting to anything outside his network, much less installing any new packages on his machines?

These are quite common scenarios for many sysadmins. And in either of them you'd be screwed without at least a working knowledge of vi.

Don't get me wrong, emacs and TRAMP are great! They're just not always available when a sysadmin needs them.

I'm actually puzzled by the discussions in this thread. Just use lftp, and the editor of your choice to edit the files?

EDIT: gnosis mentioned why https://news.ycombinator.com/item?id=5730714 . i've only come across those cases a handful of times though

>Fine, install mg, it'll do 90% of what I need.

oh no, mg is pretty crappy. I use a lot of emacs features and the ones I just need on that file are usually not available.

If I need to choose between mg and vim I'll always use vim, it's far superior than any of these cheap emacs clones.

Use a real Emacs or use Vim... that's it.

Ever since I tried OpenBSD I have replaced vi with mg. However, what if you SSH into someone's server and you have no Root access ? Sometimes you just need to know some Vi basics.

> However, what if you SSH into someone's server and you have no Root access?

I'll suggest that mg be installed, as I always do. Or I'll use TRAMP. Hell, if push comes to shove I can scp mg's tarball and compile it there to get a local mg.

> Sometimes you just need to know some Vi basics.

The number of times I've seen that happen is 0. Literally.

mg is super nice, but I wish it had unicode support.

Torvald's Microemacs uEmacs supports Unicode if I remember correctly: https://www.kernel.org/pub/scm/editors/uemacs/

Never tried it, maybe I should.

I love vim but for some tasks (Clojure, Scala) it seems emacs is the better option, so I've recently tried to switch over to emacs + evil for these tasks. However: While my MacVim (and terminal vim) looks quite beautiful these days, due to all these splendid plugins and color themes (powerline etc) that I installed, I have to say that emacs looks awful. I did search Github for nice Emacs configs that make it look more pleasant (just using Solarized doesn't cut it for me) but I couldn't find any.

Does anyone have tips for nice emacs configurations that make it look a lot more beautiful?

Edit: My current vim looks like this (opened random old files) http://appventure.me/vim.png

My GVim: http://i.imgur.com/5nH37zy.png

My Emacs: http://i.imgur.com/SNTZL6i.png

At first, Emacs font rendering felt weird to me, but some tweaking made it look slick. I use the ir-black theme with the Monaco for powerline font. Here's my config: https://github.com/mgill25/dotfiles/blob/master/emacs

I see NERDTree on your GVIM screenshot, yet no equivalent in Emacs. I don't know about you, but I missed NERDTree very much, so I looked at speedbar in Emacs. Unfortunately, out of the box it displays as another WM-level window (frame in Emacs parlance), but I managed to beat it into shape with: http://www.emacswiki.org/emacs/SrSpeedbar

Speedbar is good, because not only looks like NERDTree, it also displays summary of file contents (for programming: functions, classes, imports, etc.) if you want.

Thanks. I'll give it a try. I do miss NERDTree in Emacs, but so far, I've only been tinkering around with it, and still use vim for long sessions. :)

I try to move on to Emacs as my full time editor/IDE, but so far I failed, and I've been trying for several weeks now. The problem is that I put years of tinkering into my VIM to make it almost exactly as I need it. This means that I won't switch until Emacs has at least very similar number of customizations, macros, plugins, etc. And making this from scratch takes time. The only positive in this is that I already know what I want, so hopefully it'll take shorter than for the first time :)

The reason to move to emacs is exactly because it has far more customizations available than vim does. Emacs' nerd tree equivalent is called undo tree, and its fantastic.


No. NERDTree is file explorer, it has nothing to do with Emacs's UndoTree. The "equivalent" of UndoTree in Vim world would be Gundo.

Thanks! That looks way better than my current emacs! Will try it out

Emacs has its own version of powerline. You can turn off most of the annoying frills like the menu bar, the scroll bars, the toolbar and the fringe. You can also use a nice typeface (I'm very partial to Deja-vu Sans Mono) and a nice color scheme (I like blackboard).

I think the final result looks rather good: http://jelv.is/emacs-blackboard.png and http://jelv.is/emacs-demo.png.

That looks nice, do you have the config for that available somewhere? Thanks!

My actual .emacs file has a ton of things unrelated to this, so here are the relevant bits:

    ;; Make the window simpler
    (tool-bar-mode -1)
    (scroll-bar-mode -1)
    (menu-bar-mode -1)
    (fringe-mode 0)
Powerline and the color theme are installed separately. You can get powerline using the new package manager through M-x package-list-packages. You might have to configure some additional package sources first:

    (require 'package)
    (add-to-list 'package-archives 
                 '("marmalade" . "http://marmalade-repo.org /packages/"))
    (add-to-list 'package-archives
                 '("melpa" . "http://melpa.milkbox.net/packages/"))
You can then run powerline using

    (require 'powerline)
It might take a little more configuration to get the powerline colors matching to what you want. You can also customize the shape of the separator: it doesn't have to be an arrow.

Unfortunately, the blackboard theme in the package manager is using the old color-theme package which has been made obsolete with Emacs 24. You should use the version ported to the new and improved theming mechanism[1].

[1]: https://github.com/don9z/blackboard-theme

Download that and put it in ~/.emacs.d/themes. Now you can set it up with:

    (setq custom-theme-directory "~/.emacs.d/themes/")
    (setq custom-safe-themes t)
    (load-theme 'blackboard)
I hope that helps.

Thanks, fantastic! Will try it out!

You might like color-theme-sunburst.el based on your screenshot.

I recently started using ujelly https://github.com/marktran/color-theme-ujelly which looks similar as well.

How do you install/load it in emacs? I moved the .el file into .emacs.d/themes, but (load-theme 'ujelly) didn't work like it did for blackboard.

Just based on the name, it looks like that file uses the old color-theme-mode instead of the new theming facilities. You'll either have to find a different version, port it over (I don't know how much effort that would take) or just use color-theme-mode.el again, which is a little annoying.

Something like this ...

(require 'color-theme) (color-theme-initialize) (load-file "~/.emacs.d/themes/color-theme-sunburst.el")

I don't know if this is what you're thinking of when you say beautiful, but I'm pretty happy with my current setup: http://i.imgur.com/m6cIbd0.png

It's basically a slightly tweaked version of color-theme-zenburn with rainbow-delimiters mode, (setq font-lock-maximum-decoration t), and modeline tweaks from http://emacs-fu.blogspot.com/2011/08/customizing-mode-line.h...

Thanks, that looks nice, do you happen to have your config available somewhere?

I think this is everything you'll need and it seems to work without the rest of my emacs config, but you can also submit an issue or email me as kate on tupl.es (and yes, that's a horrible DB joke) if you have trouble and don't want to continue the discussion here.


I don't have it up and it's scattered through different parts of my config, but I'm happy to extract those bits and toss it up as a gist in an hour or so when coffee kicks in.

Which font are you using? I can't quite place it.

Not him, but maybe its Ubuntu?

(Her actually.) It's M+ 1mn Light (M+ fonts, Type 1, monospace). I think the whole family is attractive & readable and for programming on OS X I wanted something with a lighter font weight (it's got 5) to compensate for OS X's overly heavy rendering of light text on dark backgrounds. For Linux/BSD terms I tend to use either the medium weight or use monofur.

Samples: http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/design... Design: http://mplus-fonts.sourceforge.jp/mplus-outline-fonts/index-... Bitmap font which I havent used: http://mplus-fonts.sourceforge.jp/mplus-bitmap-fonts/design/...

Awesome, thank you! Spent 30 minutes this morning running through Identifont with no luck :)

Think I prefer prefer the look of the regular weight on high DPI though:

Regular: http://cl.ly/image/0r3B1M3C2a0I Light: http://cl.ly/image/2Q1s0m1a0z3R

You're welcome. I never think of it as an obscure font family so I didn't list it, but I guess it's not so well known. I can see what you mean about high-dpi though Regular is still a bit too heavy for my tastes, I've just spent too many years on linux terminals that render light-on-dark much lighter. I run at 12-14pt in iTerm2 on a low res 13" mbp, so that may make a big difference as well.

That looks a lot like Pragmata Pro.

Not Ubuntu. The middle vertical bar in the m would be shorter.

I'm wondering what font this is, too.

> I have to say that emacs looks awful

I thought pretty much the same, until I recompiled it using Athena widgets, which brought it back to its intended glory.

Can you share a screenshot?

What do you want to achieve? "Beautiful" is very different for different people :-)

I'm using my own color scheme (example, https://img-fotki.yandex.ru/get/3314/ottalex.5/0_23992_5fbf7...). If you want, you can grab my configs from https://github.com/alexott/emacs-configs/ (mac os x-specific parts in rc/emacs-rc-local-flash.el)

I quite like the cyberpunk color theme. Wondered if it was a bit gimmicky at first, but it has stuck. http://imgur.com/eRnb1uL https://github.com/n3mo/cyberpunk-theme.el

My current vim looks like this, I rather like it dark etc


Did you try Emacs in the terminal? If Vim looks good in your terminal, then Emacs should be about the same.

What is your current config?

Looks like you want global-linum-mode to get line numbering. then to remove tool, menu and scroll bars do (tool-bar-mode -1) (menu-bar-mode -1) (scroll-bar-mode -1)

I found global-linum-mode to be rather slow in large files, unfortunately. Are there better alternatives that show the number for each line? At the moment, I’m using column-number-mode to see the current line/column in the status bar, but I’m not too happy with it.

I know it's probably a personal preference thing, but do you really need line numbers? I've never missed them. Even if I'm not jumping to a compile error (or grep result, etc) with M-g n, I can always go to a particular line with M-g g, or show what line the cursor is on with what-line. I've also got flymake next and previous warnings mapped to similar keys.

Where can I find that vim color theme? Did you had to do anything special on a 256 color terminal to make it work?

The config is on my github.com/terhechte can't look it up right now I'm on a wedding, color scheme is jellybeans :)

This suffers from the issue that other introductions to Emacs* - including the official tutorial - suffer from: a focus on Emacs community mores. It skips over the idioms that make Emacs important and focuses on the predicate tribe-member?

The power of Emacs is being command driven. The command for moving to previous line is:

The mini-buffer is where one enters commands. The command for switching focus to the mini-buffer is:

Tell the new user what is really going on. To move to the previous line: a) enter the command <M-x> to switch focus to the mini-buffer b) enter the command <previous-line> to move the coursor c) after entering the command, focus will return from the mini-buffer to the invoking buffer.

I don't have a hangup about calling <alt> "meta". New users already have somewhere to hang the mnemonic. On the other hand, until they have somewhere to hang <C-x p> it's not a mnemonic, it's just a weird way of doing stuff. In fact, giving the learner <previous-line> gives first, them somewhere to hang it.

What is typical of tutorials is that they jump past the well considered abstractions of the Emacs code, right into a set of customizations that made sense for the staff of MIT"s Artificial Intelligence Lab in 1979. These customizations were based on expertise with the software; the limitations of console interfaces with no drop-down menus, etc.; and most importantly many years to develop shortcuts on an ad hoc basis both for practical reasons and for the simple joy of productive laziness.

Perhaps <next-buffer> and <previous-buffer> are canonical illustrations of the way in which Emacs tutorials are more based on tribalism than pedagogy.

  C-x <-
  C-x ->
Could just as well be <C-b p> and <C-b n> or for that matter <M-b p> etc. or <M-x p> etc.

In the late 80's I went to vocational school to study architectural drafting, in no small part in order to get my hands on AutoCad. Part of that interest was AutoLisp. The best way to explain the idea behind AutoCad is that it was Emacs for vectors. And to some extent it still is, but there are increasing layers of abstraction. The important point is that it was and is command driven.

At the time I started with R10, there was no command aliasing except via Lisp expressions. So the alternatives were using graphic menus or typing full commands - e.g. "line" for the line command, "polyline" for the polyline command, "circle" for the circle command etc.

AutoCad output was controlled by pens and pens were mapped to the colors displayed by objects on the screen. The typical use was to map different object colors to different pen weights in the output device (in fact this was the only practical way to vary line thickness produced by the output device for a large number of objects).[1]

Now, pen mappings pretty much needed to be standardized within an office because object colors were embedded in the drawing database, and despite their arbitrary nature, the number color mappings one needed to remember were small, they all displayed on screen like crap, and one only dealt with them from time to time.

As I switched between firms, each firm had their very own mapping of colors to pen weights. Each office's "standards-guru" would justify their selection of color->thickness as being obviously logical.

"Red is obviously the color for the widest pen because it is color index 1." [2]

"Blue is obviously the color for the widest pen because it is looks the darkest on screen."

"Yellow is obviously the color for the widest pen because it is looks the brightest on screen."

"Red is obviously the color for the narrowest pen because it is color index 1." [And so it goes]

The logic underlying Emacs shortcuts is identical. It doesn't make sense beyond, "This is what I like." All of it is subject to change - even M-x and C-x. That's the power, and that's what should be taught to new users.

What makes the application of the logic bad is that the number of "What I likes" and since the command language is completely customizable via elisp, there is no justification of standardization of shortcuts except within the Emacs tutorial infra-structure. I.e. it is simple just to copy the previous tutorial that was written for the AI Lab's undergraduates on work-study in the fall of 1982. It is somewhat analogous to the "standards gurus" who prohibited changing the command alias c->circle. Though they were more frequently ignored.

[1] Certain types of objects [traces, poly-lines] had a width property inherent in them and could be used reasonably for small data-sets or special cases.

[2] Colors were indexed from 0-255 with ACI[0] being "byblock" so the logic was actually faulty.

* it also suffers from the fact that it is poor graphic design and poor typography, in my opinion. I'll leave aesthetic points about learning Emacs starting with leaving Windows for an OS with Vim as an exercise for others.

Challenge: embody your very interesting views about exposition and the need to explain 'what is going on' in a document that can be printed on one side of A4 and that allows someone to start editing text with emacs/mg.

I for one would be interested to see how your approach pans out as an accomplished design.

I have a mental image of a stack of buffers being shown as a sheaf of overlapping 'cards'...

I will. After I finish my current art work. It is titled "Chess Grandmaster on the A4."

Are you suggesting that it is impossible to embody your explanatory ideas in 'cheat sheet' format? If so, that rather renders your objections to the original article moot!

Do all introduction texts need to be in cheat sheet format? Or is there room for an introduction that is a few pages long, but follows a different format than most other few-page-long introductions?

I'm no expert but I would say there is always room for a different approach. Why not draft up a rough idea and post it here?

Sorry to enter so late but: the reason he will not do it seems to be "that does not fit with my way either of seeing it or of explaining it". I tend to agree with him on that.

I guess learning emacs requires some will to learn the environment and this implies reading text.

As for cheat-sheets there must be hundreds. If all you want is basic editing, jus anyone including save, open, quit and search must be sufficient.

The practical reason is that learning Emacs is currently a long term project, and the serious study won't begin until I get around to buying a hard copy manual. I know my learning style. It's depth first. I'm bookish.

So, I'm developing an outline - a sketch of what Emacs actually is. To me it looks like AutoCad of 1991 with a less powerful graphic interface - AutoCad had screen menus which were a context sensitive text based menu system. The difference between that and the <handfull> of Emacs extensions I have seen is that AutoCad screen menus were persistent and had a dedicated slice of the "window" (right or left side). They paged and predated pull downs in the interface.[1]

Anyway, the picture that is coming into focus is that what tutorials are teaching is not the language of Emacs (commands and eLisp), but the language of Emacs users (shortcuts).

Beyond that, Emacs command language uses a verb-noun structure. This is both a natural product of its Lispy origin and lousy for users.

[The following examples are fictitious]

Lisp thinking tends toward being about processes not objects. A programmer will create a higher order procedure <make f> contracted

  procedure -> procedure. 
Call <make buffer> and get <make-buffer>. Call <next line> get <next-line>, call <previous line> get previous-line. It's all nice and tidy from a programmer perspective.

It sucks for the user. The user needs a buffer. Is it <create-buffer>, <new-buffer>, <add-buffer>, or <make-buffer>?

Auto completion doesn't help. The user cannot easily conjure the proper demon. This is where object oriented conventions rule the field. If the user knows the kind of spirit, they know the first half of the spell, [2] and auto-completion is much easier. <buffer.next> <buffer.new> are more user friendly.

Just because from the perspective of the code <next-buffer> may be more akin to <next-line> than it is to <previous-buffer>, it is not akin semantically. There may be a natural language which uses prefix notation, but even if there is, few computer users speak it natively. When Emacs was a tool for a small community familiar with Lisp, verb-noun probably was not an impediment to learning its intricacies. Now it may be something a full fledged tutorial needs to be cognizant of.

[1] http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%...

[2] Ableson and Sussman rock.

Wow that was a pretty nice answer. Yes, all the points you make are right.

I guess that learning emacs requires a will to spend time at the loo reading about it... Otherwise its pro-oriented syntax gets in the way at all times.

I used to use icomplete-mode (incremental completion for M-x), and now I use helm. Helm allows me to start typing "M-x buffer next" and see next-buffer and switch-to-next-buffer as the options. =)

I'm not the original poster of the idea (although I think it does have merit). I'd like to see this fleshed out a bit more.

Finding a good set of key bindings is unfortunately not all that easy, and something I'd rather not have to do. What's frustrating is the lack of consistency within linux as to what are appropriate keybindings at the OS/Application level which results in a lot of binding conflicts (Unity, tmux, and most tiling window managers come to mind).

The default emacs keybindings strike me as particularly insane and not suitable for productivity or long term wrist health, but I use them because I don't want to go through every different mode as well as tmux, and my wm to figure out which bindings are going to clash.

I know that I should do it, but I'm lazy. If anybody has a really thought out set of bindings that are optimized for minimizing chords and sequence length as well as conflicts I would love to know about it.

What I'd really like is a scientific project to come up with a control scheme for the OS and emacs that maximizes keyboard efficiency.

The default bindings suck because (1) your control key is in the wrong place and (2) your meta key is in the wrong place. The first goes to the left of "A", the second underneath "/". Seriously: remap (getting meta right is hard, as keyboards aren't consistent about what they put there sadly) and try it again. When done right, your fingers stay closer to the home row than even vim (which requires frequent excursions to the shifted number row).

Nah, I have remapped those keys and the problem for me is the chords which sometimes require three or more actions for commonly used commands.

"Finding a good set of key bindings is unfortunately not all that easy, and something I'd rather not have to do."

There is nothing in the idea of teaching <next-line> as <M-x next-line> versus <C-x n> which requires finding a new set of key bindings. Emacs will even helpfully remind me every time I type <M-x next-line> that it is bound to <C-x n>.[1] That's an absurdity within the standard approach to Emacs tutorials.

[1] I am assuming that this is not just a feature of the Emacs configuration I downloaded as part of LispCabinet. http://lispcabinet.sourceforge.net/

I gave up looking for the perfect set of bindings and just switched to using evil-mode. While not perfect, definitely good enough and widely used.

Emacs' default bindings are also widely used but the chords are indeed horrendous.

There is ergoemacs.org though I gave up trying to adjust myself.

I agree that the specific key bindings are the least interesting thing about Emacs.† This is the approach I tried to take in my tutorial: http://david.rothlis.net/emacs/howtolearn.html -- namely, teaching you how to find the commands you're looking for; finding the key binding is trivial once you know the name of the command. If you have time to cast your eye over the tutorial, I'd love to hear your feedback.

† However it doesn't really pay to customise the basic key bindings away from the defaults too much, because all the major & minor modes have key bindings carefully thought out to be consistent with the defaults.

The section of the tutorial on <vc-annotate> was along the lines of what I am getting at - i.e. the starting point for everything is <M-x command>. As critique, my opinion is that this should be the approach of introductory tutorials from the point immediately following "Installing Emacs."

The general argument form of:

  <there are lots of default keybindings -> learning default keybindings>
is premature optimization for introductory Emacs tutorials - at least anecdotaly. The scattered evidence is that the default key bindings contribute to people abandoning the activity of learning Emacs. This is to say that it is reasonable to assume that default key-bindings are an impediment to Emacs adoption by new users and that thus the benefits of consistency between default bindings and calendar mode and IRC chat mode and email mode, etc. are never realized by most new users because they give up on the process and only a small percentage of those who adopt Emacs to some degree wind up living in it full time.

The argument form also ignores the idea that key-bindings can be aligned programmatically. Emacs is designed for programmers, after all.

In my opinion if a tutorial emphasizing CUA makes adoption rates higher, then the tutorial is more successful. The idea that CUA is not good Emacs is a social more, not an Emacs idiom. The emphasis on standardized keystrokes as the starting point in Emacs tutorials, logically parallels the idea that the first step to learning Emacs is to remap the keyboard to Dvorak for efficiency.

Someone wants to learn Emacs. They start with the standard Emacs key-mappings. Now they have two things to learn...

The second is the language of Emacs. The first is the gang-signs of the Emacs community.

The Emacs model has a command language and a means for making command language abstractions, elisp. The ability to make keybindings is feature of the process for making abstractions in the command language, individual keybindings themselves are values.

> if a tutorial emphasizing CUA makes adoption rates higher, then the tutorial is more successful.

That's very insightful. Thanks!

Do you know of any tutorials that follow this "deep dive first" approach? That's exactly how I like to learn.

I learned AutoCAD commands in the bathroom. Using a printed manual. When I get serious about Emacs, I will send RMS $45.



For example, this chapter: http://david.rothlis.net/emacs/customize_c.html

walks you through this example: What command is run when I press TAB? How do I find out? How do I find its (elisp) source code? How do I find the documentation for built-in elisp functions or macros or "special forms"? All culminating in figuring out (from the elisp source code) which variable you can set to customise your indentation level.

Seconding this... as someone likely to pick up emacs soon (for Clojure), a recommendation would be great.

I tried that back when I was learning Clojure. I ended up ditching Emacs to use a more immediately familiar environment (Eclipse w/CounterClockwise plugin).

I wouldn't say never learn two things at once, but I'd be aware of the extra mental load you're creating for yourself. It definitely makes things more challenging.

I agree with this completely. I use emacs for clojure and I really like it, but learning a new language and a new editor at the same time is going to make things harder. There are clojure plugins for most popular editors at this point. Learn with an editor/IDE you understand and like and then switch editors later on if you want to.

Point taken, thanks. I'm familiar with Eclipse for Android, but considering I'll likely be abandoning it for that purpose given the new platform, I'm hoping to pick up emacs not just for Clojure but for a general non-nano CLI text editing default.

For clojure, I'd actually recommend using light table. From my experience with the latest dev versions, the learning curve isn't hard at all and immediately having your code evaluated is pretty powerful and intuitive. [I started learning clojure recently as well]

I used to think the split between vim and emacs users was roughly 50/50, but reading posts here it seems more like 90/10. Why is it that people here prefer vim to emacs? I'm not asking why is vim better than emacs, but what is it about HN that means more vim users. Certainly in free software circles emacs is equally popular. Is it just a cultural thing where people tend to stick with what they first learned and what their coworkers are using?

Vim is a nifty editor, using Emacs is for most a major investment in adapting your workflow to it, Emacs users tend to want to do everything possible in it. Of course you can use Emacs as just another editor, but the culture around it is to use as a multi-purpose toolbox. It's not so strange that Emacs users would be fewer but far more invested.

For Vim users the keybindings are essential, but for most the scripts aren't that important, that's why other editors can seduce them by offering vi keybindings. But an Emacs user shivers at the thought of losing all their elisp.

(Note: Vim user)

> But an Emacs user shivers at the thought of losing all their elisp.

For one's own machine yes, for editing on somebody else's or on a server... meh. I'd sooner have a barebones emacs (aka mg) than have to use vi, if only because I'll corrupt half the file in about 10 seconds in vi.

I think it's partially a cultural thing and partially, the fact that one is an editor and the other one a bit closer to a lifestyle choice. Even if you just google them and read the snippets - vim will tell you that it's a vi clone and looking for vi will say "vi is a screen-oriented text editor originally created for the Unix operating system."

Emacs will tell you it's an "extensible, customizable, self-documenting real-time display editor." That's quite a mouthful, especially if all you had in mind was to edit some text. And I say this with all the nostalgic affection of a long-time emacs user.

I don't know about HN readers ratio, but I am split 50/50. Vim feels better when editing code and has many things right out-of-the-box. Emacs offers much more features in a more integrated way, but is heavy-weight, has to be customized, and has it's kludges. So I use Emacs or Vim according to my current mood. Also, although Evil is an awesome piece of work, the fact that some buffers cannot use that mode breaks the workflow too much for me.

I use vim for editing configs (especially on servers) and emacs for writing code.

But I think a lot if not most of HN are actually SublimeText fans, not vim fans.

Weirdly Sublime Text is one of the few text editors that I not only dislike, but struggle to understand the appeal that others have with it (and I say weirdly, because even with the other editors that I disliked, I've at least understood the appeal of them from an academic perspective).

The last time I tried ST2, it jarred with my system themes and didn't offer any additional functionality that wasn't already present with the other editors that I used at that time. Plus the other editors were open source where as ST2 was shareware (I'm guessing that may have changed now given the number of people who currently use it?)

I'm open to having my opinion changed though - if one of the Sublime Text fans want to put their case forward :) (Or at least better relating to why it's become so popular)

Try to thinks about the whole class of editors defined by Textmate, Sublime Text and E-TextEditor. It's mainly about offering all the features of something like Notepad++ (easy to use menus and settings, arbitrary multiple cursors, support for easy to use plugins without touching config files), plus:

- offering that unnamed aesthetic quality of "UX flow" (ie. try looking form something in Notepad++'s settings panes - Eclipse will seem nice and clean in comparison!)

- being cross platform and easily runnable from a memory stick

- having what feels like "no learning curve" - you can basically move from Eclipse or VS and be productive in Sublime Text from second 0, and achieve enough productivity to actually be in "coding flow" after just 1hr spent learning the shortcuts and hunting for needed plugins

- following the "don't make me think!" philosophy: this basically restates the first and the previous points and captures in one sense the "unnamed quality" that this class of editors aspires to. I you want to understand "the zen" of this, think of the multiple cursors workflow where you'd catr+click 3 different places and start typing and the alternative would be doing a regex-based search and replace on a selection (or a bloody copy paste to the 2nd and 3rd location, I know... but pretend you didn't think of this :) ), but his would actually require you to "think" about what you are doing, therefore breaking the "don't make me think" philosophy.

...all I've said above has many holes, but I understand the appeal of Sublime Text (and I actually use it - it's my favorite tool for editing plain text files, yaml files or html/js/php soup). Though, for real work, nothing beats a decent IDE with a good Vim emulation plugin :)

> multiple cursors workflow where you'd catr+click 3 different places and start typing and the alternative would be doing a regex-based search and replace on a selection

Oh so that's what multiple cursors are for! People kept telling me that sublime supports multiple cursors and I could never understand what the hell I would do with multiple cursors.

Not that your example makes me want them any more than before, though.

True that. I tried getting into the whole Vim/Emacs war. While Vim seemed relatively easy (I already had some experience with Vi) Emacs was a chore to work with.

Sublime Text gets the job done, fast and painlessly.

I wanted a default tool I could find and use on any machine I connected to. vim is always there, even on servers.

I wanted something I could use over SSH, even on really bad connections such as mobile. vim works great over poor connections.

I barely use plugins, and seldom configure syntax highlighting.

On the desktop I may use vim, but tend to use Sublime Text for everything. Go, Java, HTML, CSS, JavaScript (node and browser)... Sublime Text serves me really well and works the way I want to work. Before Sublime Text I was 100% vim, after Sublime Text I'm 80/20 ST/vim.

But for whenever there isn't ST, vim is always there.

> vim is always there, even on servers.

This argument made sense 20 years ago, when it was quite possible that you'd fine yourself on some weird IRIX machine that had nothing much installed, but you could be sure vi was there.

These days, apt-get install emacs or the redhat equivalent is not really a problem.

> I wanted something I could use over SSH,

Emacs has a remote connection mode, so that you fetch the file, edit it locally, and then save it to the remote machine.

It still applies, servers I connect to tend to be locked enough that users are unable to install stuff. The user (me) would need to get a ticket opened to have it added to the config, whereas vim is already there.

And on the latter, if the issue is a live server needing immediate attention and a config change, and I'm mobile and using my Android device and have the rights to edit a file and the access certificate locally I could just do it in vim in moments over SSH. Whereas I've no clue as to what app I'd need to install on my phone to act as a passable editor for the file, and why retrieve a whole file (potentially large config) when you just want to make a one-line change? vim just works for my use-case, no config required, no local app required, just edit the file, save it, test and be done.

Both of those solutions just feel clunky, why fight to use Emacs when you could just use vim? Hence, I just use vim, it works, I'm happy as the job is done.

> Both of those solutions just feel clunky

They're not any clunkier than the solutions you were preferring. I think what's happened here is that you've found a solution that works for you and your happy with. Which is fine. But you're then trying to rationalize why your solution is "better" when really your solution is just personal preference.

However with that all said and done, I'm a vi use myself. I've never seen the point of learning emacs because I like vi, I'm quick in vi and I'm happy with vi. But if I'd learned emacs before I learned vi, then I'm sure I'd be saying the same thing but :%s/vi/emacs/g

I for one wanted to do some tedious non automatable box editing over ssh, emacs have a default extension (mode?) to do this which did not worked in the terminal, tried some quick stuff on config, did not work. Every page I found on how to fix the stuff forced me to read for more time than I had to do the task, I just did it with vim.

I'm just trying to learn some emacs and although I see its value, the emacs experience is not for me, my vimrc is like every other config file that I have, a bare minimum. People who use emacs generally tweak the editor with thousand of lines of elisp.

I use Emacs for org mode and other things that I want to run in a terminal that I can stuff into Emacs, such as an IRC client. I use Vim for code editing. Sure, you can use Evil, but I feel like Vim is more than keybindings. I love Vim for the whole package, the Vim way of doing things and you can't get that using just Vim keybindings.

I use Tmux for managing multiple sessions, so I generally have a lot of Vim sessions going at one time. Emacs is just another session for me, so it's a regular part of my workflow to switch back and forth.

I think that's almost 100% cultural thing. I know both editors quite well now, and to learn them I had to read tons of people's posts and such. In Emacs (unofficial) writings I saw much more "holier-than-thou" attitude, similar to what they call "smug lisp weenies". Vim's writings are down to earth, focused on pragmatics and making no unneeded comparisons.

While technically Emacs users and advocates are right, they lose big time in "marketing" or "public relations". I don't really think that this is going to be fixed.

I started out using vim because when I first looked at it and emacs, vim seemed like the more elegant of the two. I tried both out one afternoon, and the commands in vim made more sense to me than those in emacs. But after taking a class where we were basically forced to use emacs, I've really come to appreciate it more and have found myself much more productive in it than in vim.

I prefer Emacs, but sometimes think Vim works better on laptops as everything is right under your fingers. Emacs is much more comfortable on a full-size keyboard. So I wonder whether there's any correlation between Emacs/desktop and Vim/laptop.

There was a post (or was it a comment) here a couple months ago about Emacs/Vim users and the sizes of their hands.

I have tiny hands and when I tried (still trying every now and then) to learn Emacs, I found it difficult to execute its keyboard commands. Trying it on a mechanical keyboard was even worse.

I had a similar issue until getting a HHKB[1] some years ago. The extremely compact design with full-sized keys made it much easier to coax my hands into dancing through emacs' chords.

As "buy an expensive keyboard to possibly make learning emacs easier" is the advice of the mad, I would suggest that you be fearless in rebinding things. Learning the default bindings is far less important than learning the functionality of emacs and how to extend and customise it.

[1] http://en.wikipedia.org/wiki/Happy_Hacking_Keyboard

my whole office use emacs for clojure dev but I use vim. I tried emacs for a few days on more than one occasions but simply couldn't bear the physical awkwardness of the key combos (I did remap ctrl to caps).

I'm glad someone mentioned this. I used emacs for years and was totally ignorant of vi/vim, but I started getting pain in my hand from all the key-combos. I was skeptical of modes, but it turns out to be pretty natural, and I actually like the concept of editing as a sequence of transactions with a start and end, rather than one continuous stream. I've never gone overboard with customizing either editor, so for me it was primarily ergonomics.

Try Evil Mode with Emacs for Clojure. Its pretty close to vim

I use emacs but I also dislike the "you can rebind any keys you want, as long as the sequence begins with C-c". As it turns out emacs doesn't user the super key at all (Apple key on Mac keyboards, Windows key [I think?] on Other). You can dramatically increase the number of comfortable chords available to you by taking advantage of this, e.g.: (global-set-key (kbd "s-l") 'forward-word)

While the OS-specific keys are sometimes called super, they are not "super" in emacs terminology. Also, if you skim M-x describe-bindings you will find quite a few bindings beginning with s-.

EDIT: If you really want access to a less crowded namespace, using (global-set-key "\C-z" nil) to free up the c-z prefix and binding Hyper are popular.

If you are feeling a little confined, key chord[1] will allow you to get creative with your bindings.

[1] http://www.emacswiki.org/KeyChord

Not using a Super key is actually a great feature. My Super key is used solely in the AwesomeWM (a window manager) commands, so the two (awesome and emacs) never clash on who will handle a key combination.

I was very unpleasantly surprised when I discovered that OS X uses a single Control key for some of its hotkeys (like C-up/down) which I bind in Emacs for my own purposes.

I've never paid attention to the C-c convention and liberally bound commands to whatever key I preferred.

I agree with step 1 -- learning vi[m] is damn useful since it's almost always available.

The rest of the one-pager seems to me like "here's how to understand other stuff about emacs that makes no sense to the uninitiated" -- e.g. "M" in keyboard shortcuts refers to alt or the Apple command key. In terms of getting stuff done, the one-pager barely gets you to the point you'd be at with no instruction at all using Notepad on Windows 3.1. [sarcasm] Oh look, there's a calculator! I can launch a handy command-line tool called the command prompt. I can create multiple views side-by-side. Wow. [/sarcasm]

As an aside, has someone tried building an editor which leverages the GUI familiarity many of us have ingrained thanks to 30 years of UI progress which still gives you, say, instant access to lisp or python automation which is seamlessly bound to the editor? That would rock.

@Techendo also has a how-to by Tim Jarratt on How-to Emacs: http://www.youtube.com/watch?v=_d_uf_Ddj-8

I've had these floating around for a while, leftover from some Unix class I taught a while back, both graphically-oriented reminder charts, rather than exhaustive lists, of the most basic commands needed in both editors:



Nice. However, I object to the "edit .emacs" part. I found out that most of the things that were in my .emacs could be set via M-x customize. I don't see the point of editing the configuration file instead of using the configuration interface, in particular when one addresses new users.

Because the power you get by having a Lisp program as your config file is what makes Emacs what it is.

When my emacs starts, it checks things like the size of the screen and what windowing system is running and picks fonts and sizes accordingly.

It depends. Usually configuration interfaces are made for two reasons: to be more "user-friendly" and to reduce the possibility of erroneous input that might confuse the parser. In this case, the emacs config interface is (arguably), not "user friendly", and emacs is usually forgiving of malformed input (it may stop loading your config, but it won't crash and it will tell you how to debug it).

It's advocacy that people learn vi in some cases prevents me from sharing this link with others.

That's a pity, as I find it helps me to be open-minded about editors. =) Still, it's Creative Commons-licensed, so feel free to make a new version. (Or even a version with a blurred out or redacted section... =) )

> That's a pity, as I find it helps me to be open-minded about editors. =)

You only think it helps you. In practice, you are exposing people to the the darkness.

> Still, it's Creative Commons-licensed, so feel free to make a new version.

For the record, you are awesome for doing that.

I thought we got over editor flamewars ten years ago?

Seriously, though. Try different editors, figure out what works for you.

> I thought we got over editor flamewars ten years ago?

We did... and Emacs won. ;-)

> Seriously, though. Try different editors, figure out what works for you.

Absolutely. It's the best way to separate the chosen ones from the heathens. ;-)

"M-x replace-string RET"

Try M-% instead.

Text editor is too complicated if you need to learn how to use it..

Well, yes. However, emacs isn't a text editor in the sense you're probably used to. Or at least, it kinda is but that's not the main selling point. Teaching people to cut and copy and so on in emacs is a bit of a waste of time if that's all you're going to show them - there are plenty of tools out there to do that which you don't have to learn. No-one cares if control n moves you down a line when they have arrow keys that do that perfectly well in every other program. That's not a good reason for moving to emacs over notepad++ or the like.

The big selling point of emacs, really, is that it's command driven - and you can go write the commands yourself. All the boring little tasks that you do while writing normally? Changing variable names in multiple places, if you have largely formal constructs you use a lot-

if (dah de dum de dah) {

} - that sort of thing. You can even insert a formal construct and then have parts of your typing mirrored out in it.

You can give yourself multiple cursors with their own buffers so that you can work on multiple lines with similar constructions if you're making pattern type alterations to things.

Any problem that's structured to follow the same sort of pattern, you can probably make the text editor do them for you.

That's more along the lines of why people might want to use emacs. There's a lot of dead-time involved in typing things out that can be automated if you've the tools.

Powerful tools have a learning curve. C++ and Git take longer to learn than JavaScript and SVN.

Computer is too complicated if you need to learn how to use it..

For quick little tasks, writing blog posts, or system administration, Emacs or VIM or Sublime all work fine.

For most professional software engineers, reading code and thinking take up 80% of the job; typing the changes takes up about five percent. For these professionals, I've found that a modern IDE with good code browsing features will save the most time, overall. Jetbrains' products, SlickEdit, or Eclipse come to mind.

This seems to be the conventional wisdom, but as with most such things it's more conventional than wise. Once I thoroughly understood Emacs, I found it significantly better for navigation even through languages like Java.

A combination of ido-mode and dired make it incredibly fast to go through the directory structure of any project. It's also really easy to open a shell wherever i am visiting at the moment--including remote directories!--which I've found incredibly useful.

Once I'm in a file, there are a whole ton of movement commands in Emacs that make teleporting around natural. Just one example that seems hard to duplicate in an IDE is the mark: in the course of normal editing, you often set the mark to do things like highlight regions of code. Then, later on, you can cycle back through your old marks, which takes you back through the parts of the file that you were active in. It's like bookmarking a line in the file, except much more lightweight--it happens in the natural flow of working on a file. This is just one example of many very productive features.

Another great example is rgrep. This command lets you search through files in a directory. However, the really cool thing is how it displays the results: you get the filename and the line where the match happened. You can go to the file directly or actually edit it in place in the rgrep results buffer! It's very nice for certain tasks.

Really, Emacs is full of incredibly well thought-out productivity boosters for everything you will do while managing software.

Moreover, it is not limited to language agnostic things. If your want Eclipse-like Java support, you can have it with eclim, which actually uses Eclipse as its backend. I also know of great IDE-like support not based on Eclipse for all sorts of languages from Python through OCaml.

Now, Emacs does have a learning curve. It will take a bit of effort to get good with it. It will probably require changing your entire workflow to take advantage of all the awesomeness. But it's more than worth the time investment: getting comfortable with Emacs is an O(1) action where the benefits it confers are a significant O(n) (if not better!) bonus. The more you program, the more you'll gain.

Learning Emacs gives you significant gains even if most of your job involves browsing around and editing existing code.

Don't get too excited about these sophomoric features. All modern IDEs have copied the best features from various editors. You can get the kill ring and set mark in IntelliJ, for example, and various other things besides.

These features are all simple hacks from twenty years ago. What's really difficult is putting in the elbow grease to polish the environment to a shine of high productivity, which is where buying a commercial IDE is a win. Code completion works better. Refactoring works better. Fuzzy completion works better. The keyboard shortcuts won't put you in the hospital. But mainly, code browsing in large, complex code bases works better.

It's really hard for people to look around and realize that times have changed, and change with them. People learn one thing and then their ways are set. It's up to the next generation to move things forward.

As someone who's gone the other way (from an IDE to a shall we say "separated" development environment), I can tell you you're wrong. For me, at least.

I've seen people impressively efficient in commercial IDEs, but the best coders I know all use a collection of simple, reliable, and predictable tools.

EDIT: And this idea that having a superset of checked feature-boxes is superiority is at the root of the problem.

A lot of programmers would like to keep it simple and fast. IDEs tend to be slow, and crash, and have extremely cluttered UIs. All the "polish" that went into designing the environment means that you can't change what you don't like about it.

Emacs:Display Editor::Java:Program Execution

The investment in learning any powerful editor would probably follow a power law, since you'd be continually learning new things. You could keep it to O(1) by choosing some subset and refusing to learn anything more. But the expectation is that time spent learning more than pays off over time.

The analogy of Emacs learning curve being a fractal is quite appropriate I think if we take each fractal to represent an amount of time required to gain proficiency in modes that introduce significant amounts of features, with the smaller fractals representing modes that require less time to learn.

That sounds like chaos, but it captures Emacs platform nature and diversity of functionality well and seems true thus far as Emacs replaces more and more tools.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact