12 ms·

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

209 points by alexott 13y ago

throwaway1980 13y 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 13y 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).
  - terhechte 13y ago
    Try Evil Mode with Emacs for Clojure. Its pretty close to vim
  - xaritas 13y 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)
    - unlogic 13y ago
      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.
    - quiesce 13y ago
      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 http://www.emacswiki.org/KeyChord
    - aerique 13y ago
      I've never paid attention to the C-c convention and liberally bound commands to whatever key I preferred.
  - mtdewcmu 13y 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.
- Swizec 13y 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 13y 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.
  - laumars 13y 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)
    - nnq 13y ago
      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 :)
- kryptiskt 13y 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)
  - masklinn 13y 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.
- gexla 13y 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 13y 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.
- buro9 13y 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.
  - davidw 13y 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.
    - buro9 13y ago
      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.
      - 13y ago
- preavy 13y 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 13y 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.
    - quiesce 13y ago
      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 http://en.wikipedia.org/wiki/Happy_Hacking_Keyboard
- astrobe_ 13y 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.
- klibertp 13y 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.
- da3da 13y 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.
terhechte 13y 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 http://appventure.me/vim.png
- alexott 13y 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_5fbf7afb_orig 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/ https://github.com/alexott/emacs-configs/ (mac os x-specific parts in rc/emacs-rc-local-flash.el)
  - terhechte 13y ago
    My current vim looks like this, I rather like it dark etc http://appventure.me/vim.png http://appventure.me/vim.png
  - justinhj 13y 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 http://imgur.com/eRnb1uL https://github.com/n3mo/cyberpunk-theme.el https://github.com/n3mo/cyberpunk-theme.el
- gexla 13y ago
  Did you try Emacs in the terminal? If Vim looks good in your terminal, then Emacs should be about the same.
- nieve 13y ago
lowglow 13y ago
@Techendo also has a how-to by Tim Jarratt on How-to Emacs: http://www.youtube.com/watch?v=_d_uf_Ddj-8 http://www.youtube.com/watch?v=_d_uf_Ddj-8
benjaminwootton 13y 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 13y 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.
- davidw 13y 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.
- gnosis 13y 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 https://news.ycombinator.com/item?id=5681534 [1] - http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg006... [2] - http://www.emacswiki.org/emacs-en/Scheme http://www.emacswiki.org/emacs-en/Scheme [3] - http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-scheme/ http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-sc... [4] - http://www.nekthuth.com/ http://www.nekthuth.com/
drothlis 13y 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 http://david.rothlis.net/emacs/howtolearn.html
blumentopf 13y ago
"M-x replace-string RET" Try M-% instead.
phektus 13y 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.
- npsimons 13y 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-emacs-proficiency http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em... http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps-replacing-my-tools-at-work http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps...
astrobe_ 13y 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 13y 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.
- npsimons 13y 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).
masklinn 13y 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.
- aerique 13y 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.
  - masklinn 13y 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.
    - dedward 13y ago
      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.
codex 13y 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.
- tikhonj 13y 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.
Lennu 13y ago
Text editor is too complicated if you need to learn how to use it..
- nijk 13y ago
  I feel the same way about programming languages, cars, and kitchens.
- justinhj 13y ago
  Powerful tools have a learning curve. C++ and Git take longer to learn than JavaScript and SVN.
- Derbasti 13y ago
  Computer is too complicated if you need to learn how to use it..
- 6d0debc071 13y 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 13y 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/emacs-hints.png http://www.talisman.org/unix/img/editors/vi-hints.png http://www.talisman.org/unix/img/editors/vi-hints.png
keithpeter 13y 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?
- sachac 13y 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!
  - keithpeter 13y 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.
brudgers 13y 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.
Tloewald 13y 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.
cbsmith 13y ago
It's advocacy that people learn vi in some cases prevents me from sharing this link with others.
- sachac 13y 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... =) )
  - cbsmith 13y 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.
    - qu4z-2 13y ago
      I thought we got over editor flamewars ten years ago? Seriously, though. Try different editors, figure out what works for you.
      - cbsmith 13y ago
        > 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. ;-)

209 points by alexott 13y ago

throwaway1980 13y 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 13y 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).
- terhechte 13y ago
  Try Evil Mode with Emacs for Clojure. Its pretty close to vim
- xaritas 13y 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)
  - unlogic 13y ago
    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.
  - quiesce 13y ago
    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 http://www.emacswiki.org/KeyChord
  - aerique 13y ago
    I've never paid attention to the C-c convention and liberally bound commands to whatever key I preferred.
- mtdewcmu 13y 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.
Swizec 13y 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 13y 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.
- laumars 13y 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)
  - nnq 13y ago
    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 :)
kryptiskt 13y 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)
- masklinn 13y 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.
gexla 13y 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 13y 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.
buro9 13y 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.
- davidw 13y 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.
  - buro9 13y ago
    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.
    - 13y ago
preavy 13y 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 13y 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.
  - quiesce 13y ago
    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 http://en.wikipedia.org/wiki/Happy_Hacking_Keyboard
astrobe_ 13y 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.
klibertp 13y 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.
da3da 13y 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.

terhechte 13y 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 http://appventure.me/vim.png

alexott 13y 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_5fbf7afb_orig 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/ https://github.com/alexott/emacs-configs/ (mac os x-specific parts in rc/emacs-rc-local-flash.el)
- terhechte 13y ago
  My current vim looks like this, I rather like it dark etc http://appventure.me/vim.png http://appventure.me/vim.png
- justinhj 13y 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 http://imgur.com/eRnb1uL https://github.com/n3mo/cyberpunk-theme.el https://github.com/n3mo/cyberpunk-theme.el
gexla 13y ago
Did you try Emacs in the terminal? If Vim looks good in your terminal, then Emacs should be about the same.
nieve 13y ago

lowglow 13y ago

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

benjaminwootton 13y 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 13y 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.
davidw 13y 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.
gnosis 13y 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 https://news.ycombinator.com/item?id=5681534 [1] - http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg006... [2] - http://www.emacswiki.org/emacs-en/Scheme http://www.emacswiki.org/emacs-en/Scheme [3] - http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-scheme/ http://www.doof.me.uk/2010/12/12/using-slime-with-chicken-sc... [4] - http://www.nekthuth.com/ http://www.nekthuth.com/

drothlis 13y 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 http://david.rothlis.net/emacs/howtolearn.html

blumentopf 13y ago

"M-x replace-string RET" Try M-% instead.

phektus 13y 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.

npsimons 13y 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-emacs-proficiency http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em... http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps-replacing-my-tools-at-work http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps...

astrobe_ 13y 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 13y 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.
npsimons 13y 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).

masklinn 13y 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.

aerique 13y 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.
- masklinn 13y 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.
  - dedward 13y ago
    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.

codex 13y 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.

tikhonj 13y 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.

Lennu 13y ago

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

nijk 13y ago
I feel the same way about programming languages, cars, and kitchens.
justinhj 13y ago
Powerful tools have a learning curve. C++ and Git take longer to learn than JavaScript and SVN.
Derbasti 13y ago
Computer is too complicated if you need to learn how to use it..
6d0debc071 13y 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 13y 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/emacs-hints.png http://www.talisman.org/unix/img/editors/vi-hints.png http://www.talisman.org/unix/img/editors/vi-hints.png

keithpeter 13y 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?

sachac 13y 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!
- keithpeter 13y 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.

brudgers 13y 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.

Tloewald 13y 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.

cbsmith 13y ago

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

sachac 13y 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... =) )
- cbsmith 13y 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.
  - qu4z-2 13y ago
    I thought we got over editor flamewars ten years ago? Seriously, though. Try different editors, figure out what works for you.
    - cbsmith 13y ago
      > 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. ;-)