How to Learn Emacs: A Hand-drawn One-pager for Beginners

http://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand-drawn-one-pager-for-beginners/

by alexott • 13 years ago

209 165 13 years ago

throwaway1980• 13 years ago

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?

plam• 13 years ago

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

terhechte8• 13 years ago

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

xaritas• 13 years ago

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)

mtdewcmu3• 13 years ago

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.

Swizec2• 13 years ago

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.

ameen• 13 years ago

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.

laumars2• 13 years ago

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)

kryptiskt• 13 years ago

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)

masklinn6• 13 years ago

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

gexla2• 13 years ago

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.

glurgh• 13 years ago

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.

buro92• 13 years ago

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.

davidw2• 13 years ago

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

preavy• 13 years ago

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.

john2x• 13 years ago

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.

astrobe_2• 13 years ago

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.

da3da• 13 years ago

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.

klibertp4• 13 years ago

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.

terhechte8• 13 years ago

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

alexott• 13 years ago

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)

terhechte8• 13 years ago

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

http://appventure.me/vim.png

justinhj2• 13 years ago

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

gexla2• 13 years ago

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

nieve5• 13 years ago

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

bitserf2• 13 years ago

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

terhechte8• 13 years ago

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

manish_gill2• 13 years ago

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

terhechte8• 13 years ago

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

klibertp4• 13 years ago

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.

tephra• 13 years ago

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)

claudius2• 13 years ago

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.

olgeni• 13 years ago

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

mietek• 13 years ago

Can you share a screenshot?

tikhonj4• 13 years ago

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.

terhechte8• 13 years ago

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

derengel• 13 years ago

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

terhechte8• 13 years ago

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

lowglow• 13 years ago

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

benjaminwootton• 13 years ago

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.

RBerenguel• 13 years ago

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.

davidw2• 13 years ago

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

gnosis3• 13 years ago

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/

enduser• 13 years ago

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.

gnuvince2• 13 years ago

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.

klibertp4• 13 years ago

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.

SkyMarshal2• 13 years ago

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

tomsthumb• 13 years ago

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.

johncoltrane2• 13 years ago

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.

qu4z-23• 13 years ago

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.

drothlis4• 13 years ago

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

blumentopf• 13 years ago

"M-x replace-string RET"

Try M-% instead.

phektus• 13 years ago

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.

npsimons4• 13 years ago

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:

http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em...

http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps...

astrobe_2• 13 years ago

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.

rbanffy• 13 years ago

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.

npsimons4• 13 years ago

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

masklinn6• 13 years ago

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

aerique5• 13 years ago

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.

masklinn6• 13 years ago

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

claudius2• 13 years ago

> Vi(m) will be there.

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

reddit_clone• 13 years ago

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

Edit everything from the comforts of your desktop!

dysoco2• 13 years ago

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.

masklinn6• 13 years ago

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

gnosis3• 13 years ago

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.

atsaloli• 13 years ago

vi is part of POSIX (the UNIX standard):

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

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

binderbizingdos• 13 years ago

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

Derbasti2• 13 years ago

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

gnosis3• 13 years ago

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.

rjzzleep• 13 years ago

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

codex2• 13 years ago

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.

tikhonj4• 13 years ago

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.

mtdewcmu3• 13 years ago

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.

codex2• 13 years ago

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.

Lennu• 13 years ago

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

justinhj2• 13 years ago

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

Derbasti2• 13 years ago

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

6d0debc071• 13 years ago

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.

erlkonig• 13 years ago

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:

http://www.talisman.org/unix/img/editors/emacs-hints.png

http://www.talisman.org/unix/img/editors/vi-hints.png

keithpeter5• 13 years ago

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?

sachac3• 13 years 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!

keithpeter5• 13 years ago

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.

brudgers6• 13 years ago

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:

  previous-line

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

M-x

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.

keithpeter5• 13 years ago

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

brudgers6• 13 years ago

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

mattdawson• 13 years ago

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

obviouslygreen2• 13 years ago

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

brudgers6• 13 years ago

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

http://shop.fsf.org/product/Emacs_Manual_24/

drothlis4• 13 years ago

http://david.rothlis.net/emacs/howtolearn.html

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.

drothlis4• 13 years ago

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.

brudgers6• 13 years ago

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.

koalaman2• 13 years ago

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.

aooeeu• 13 years ago

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

brudgers6• 13 years ago

"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/

ajross• 13 years ago

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

aerique5• 13 years ago

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.

Tloewald• 13 years ago

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.

cbsmith3• 13 years ago

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

sachac3• 13 years ago

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... =) )

cbsmith3• 13 years ago

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

How to Learn Emacs: A Hand-drawn One-pager for Beginners

Related Stories