As I've moved to more polyglot programming (Java, Javascript, Node, Ruby) I've made a concerted effort to get back to Emacs after starting out there 10 years ago.
Using the same environment for all of my coding together with the tightly has been a massive increase in productivity for me. I've literally never been producing more on my side projects mainly due to this choice.
The reduced friction of using the same IDE on all of my different devices means that I can hit flow much faster, with the same shortcut keys, the same workflows, the same tools etc at my disposal regardless of what I'm building.
I prefer Emacs to VI mainly due to the tight shell integration. I'll always have a shell open where I'll be testing my code and running curl etc, keeping the feedback loop much tighter than it ever was in any IDE.
Picking up Emacs or VI is definetly worth the initial pain if you program in multiple languages.
I can recommend evil mode to occasional uses of vi things. Though I'm the crazy guy who tried to use only emacs (or emacs-alike tools, i.e. conkeror for web browsing) for a month, after reading Practical Vim I've found out some things in vim are rather neat, and I want to use them (text objects, mostly.) Evil does the trick neatly.
Over the years, I've used Perl, PHP, SQL, shell scripts, Python, Tcl, C, Erlang, HTML, Javascript, Java, Ruby, LaTeX, DocBook and other flavors of XML, nroff (man pages), CSS, and probably other stuff I'm forgetting. Emacs always comes through with pretty good support and a familiar environment, even if the particular language is a new one. I'm confident that it will continue to do so in the future.
Unless they're on a resource starved or crippled machine, most people are going to prefer using vim to vi -- though I have run in to people who stubbornly prefer the ultra minimalism of plain vi, even when they could run vim.
So, vim, not vi, is really what you should be comparing emacs to. Vim is far more feature rich than vi, and has plugins that allow shell integration. So shell integration is not a good enough reason to prefer emacs over vim, as vim has it too. Further, emacs' shell integration really isn't that great (contrary to many claims I've heard in the past). It's pretty buggy, with random screen corruption and many keys not working as expected.
That said, there some great reasons to prefer emacs over vim (and I say this as a vim user of about 20 years who's in the process of switching over to emacs).
The first reason is eLisp. I love Scheme and Common Lisp, and much prefer to have an editor that's scriptable in a Lisp dialect. Yes, here too vim isn't quite stuck with vimScript only. It is possible to script vim in other languages (like mzScheme/Racket, Python, Ruby, and Lua). But 99.9% of vim scripts are written in vimScript, for reasons that I guess at elsewhere.[0] There are maybe one or two vim scripts written in Python, but I've never seen one written in mzScheme or Racket (or Ruby or Lua, for that matter). So, practically speaking, the vim user is stuck with vimScript after all. That's not the case with emacs, where the entire community scripts in eLisp.
The second reason is the tight integration of many applications with emacs. You could read your email in emacs, browse the web through emacs, read RSS news feeds through emacs, etc. And when you do this, you bring the entire power of emacs to bear in customizing and interacting with these embedded applications. As a result, much of your environment becomes easily extensible and customizable through eLisp, and automating repetative or complex tasks that you perform in these applications becomes much easier as well. Yes, you might be able to do something similar in your standalone browser through Javascript, or maybe your standalone mail reader might be scriptable and extendable to a certain extent, in some language or other. But if you choose the standalone application path, you're going to wind up with a very fragmented ecosystem, programmed in a half dozen or more languages, and not very tightly integrated. With emacs, everything is tightly integrated and programmed/exteneded/controlled through eLisp.
The third reason is org-mode. Here again, vim is not completely without it, as it has some plugins inspired by org-mode. But from what I've heard, they're a far cry in capability from what org-mode offers in emacs. That said, I'm only starting to dip my toes in to org-mode in emacs, and have never tried the org-mode-like plugins in vim, so I'll stop with the comparisons here. But I will just quickly mention that I've heard of people switching to emacs just for org-mode, and after using org-mode a little, I can understand why.
The fourth reason is Guile. In the not-so-distant future, Guile will bring emacs scriptability to the next level. Many things that were painful or impossible to accomplish with emacs built on C and eLisp will be able to be accomplished with emacs built on Guile. (See here[1] for details) That said, eLisp is not going away, and is not going to be fully replaced by Guile.
The fifth reason is evil mode. Emacs can do a fair emulation of vim's core functionality. Evil mode can go a long way towards making a vim user comfortable in emacs -- and in letting emacs users edit more efficiently using vim-like keybindings. (There are probably vim plugins that try to do something similar for vim, but I doubt they do much beyond providing a handful of emacs-like movement keys.) With evil mode, you get the best of both worlds.
There are probably other good reasons to prefer emacs to vim. But those are the ones I can think of off the top of my head. There are also good reasons to prefer vim to emacs. I personally find that vim provides a more usable experience out of the box, without too much hacking. But I may be a bit biassed here. This is actually an area where both editors could stand a lot of improvement, as both do require some hacking around to get the editors to a reasonably usable state. Yes, you could do basic editing in both out of the box, but really not much more (unless you're a masochist, or RMS -- who supposedly prefers vanilla emacs).
There's also less to learn and tweak in vim (simply because it doesn't have a ton of applications that can be integrated in to it -- you are basically going to be learning and tweaking its editing capabilities only). So in that sense, learning and tweaking vim is easier than learning and tweaking emacs.. or at least you'll probably spend less time doing so. Emacs is a supermassive black hole of infinite customizability, while vim is more like a regular black hole of editing-oriented flexibility.
I'd continue making an exhaustive comparison of the two editors, but this is starting to get kind of long.. In sum, they are both great and powerful editors, and you would not go far wrong in choosing either. For me, the balance has tipped in emacs' favor, but I would not begrudge anyone for choosing vim.
Update: Yes, SLIME! How could I forget SLIME? SLIME was one of the first things that attracted me to emacs. Now I'm actually much more interested in programming Scheme than Common Lisp (at which SLIME is primarily aimed at). But emacs also supposedly has some nice REPL integration with Scheme as well, including via SLIME.[2][3] It also has parens mode, which makes editing sexp's so much easier than they would be on vim (to my knowledge). That said, vim also has some REPL integration plugins, like Nekthuth.[4] They're not nearly as powerful or well integrated as SLIME, however.
Interestingly, I prefer vim to Emacs because of vim's tight shell integration. I feel like Emacs always try to reinvent the wheel, whereas vim plays much more nicely with the os shell. Just pipe arbitrary text through commands, outsource search to grep, building to make, etc. In fairness, I haven't learned Emacs yet, so maybe my impression of NIH is unfair.
And in most programs (especially vim) I'm only ever a C-z away from a shell I can use to test code, run curl, etc :)
It just makes more sense to me to host my text editor in my shell, not the other way around. But then, I guess Emacs isn't really a text editor so much as a development environment, complete with integrated shell.
Interesting that most of the comments so far (62) have been about the content rather than the form.
I rather like the form; simple, direct and 'human' through the use of hand drawn text & diagrams. The information density seems about right at one side of A4.
Does anyone else remember Donald Alcock's series of hand drawn books about programming languages a few decades ago?
That's awesome! I hadn't come across Donald Alcock's books before, and I'm glad you recommended them. I've just ordered a copy of Illustrating C. Looking forward to being inspired by it!
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. :-)
I've been using emacs for a couple of years now as my main editor, but I haven't gone past the 'casual' mode of usage - I haven't tinkered with the config file except for copy pasting stuff and never did try to create my own macros. I should try to incorporate that into my workflow very soon.
On a related note, Sacha's blog has been in my reading list since delving into 'serious' development mode six years ago. It also influenced me to try out emacs resulting to my love affair with it right now.
Be warned, you can get sucked in very easily :) Pretty soon, you're using org-mode to manage your life, then you hook up an XMPP client, start using Magit or Egg, have a shell open, and eventually it's your only app open, full screened:
I really don't understand this mindset. You don't want to install Emacs on a server? Fine, install mg, it'll do 90% of what I need. If you whine about a 170k binary when a modern vi is 2MB, by god I am not a violent man but I will throttle you with a CAT5 cable.
As a sysadmin, you have to be capable of quickly editing files no matter what or whose machine you're on.
This means that you often don't have the luxury of installing anything on the machine you find yourself on. You might find yourself on a small Linux-based router that only has busybox on it. This is the case for many resource-starved VPS' and other small Linux installs as well. Busybox comes with vi, but not with emacs (or even vim). If a sysadmin finds himself on one of these, he simply has to make do with what he has. He may not have the time, or an internet connection, or the authority to install anything at all. So familiarity with vi in these circumstances is essential.
On very few machines will the situation be reversed: with emacs or mg available and vi not (I have never run in to such a case). So a sysadmin has little incentive to learn or install emacs.
As for mg, even if you could install it, I'm really not sure what it would buy you over vanilla vi. In the kinds of resource-starved environments where you'd actually prefer mg over emacs, you wouldn't want to spend a lot of time editing anything. A quick in and out edit should really be all you could reasonably be expected to do in such a situation... and that could probably be done equally well with either mg or vi.
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.
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?
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
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).
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)
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.
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'...
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.
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.
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?
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.
I've had these floating around for a while, leftover from some Unix class I taught a while back, both graphically-oriented reminder charts, rather than exhaustive lists, of the most basic commands needed in both editors:
Nice. However, I object to the "edit .emacs" part. I found out that most of the things that were in my .emacs could be set via M-x customize. I don't see the point of editing the configuration file instead of using the configuration interface, in particular when one addresses new users.
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).
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... =) )
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.
For quick little tasks, writing blog posts, or system administration, Emacs or VIM or Sublime all work fine.
For most professional software engineers, reading code and thinking take up 80% of the job; typing the changes takes up about five percent. For these professionals, I've found that a modern IDE with good code browsing features will save the most time, overall. Jetbrains' products, SlickEdit, or Eclipse come to mind.
This seems to be the conventional wisdom, but as with most such things it's more conventional than wise. Once I thoroughly understood Emacs, I found it significantly better for navigation even through languages like Java.
A combination of ido-mode and dired make it incredibly fast to go through the directory structure of any project. It's also really easy to open a shell wherever i am visiting at the moment--including remote directories!--which I've found incredibly useful.
Once I'm in a file, there are a whole ton of movement commands in Emacs that make teleporting around natural. Just one example that seems hard to duplicate in an IDE is the mark: in the course of normal editing, you often set the mark to do things like highlight regions of code. Then, later on, you can cycle back through your old marks, which takes you back through the parts of the file that you were active in. It's like bookmarking a line in the file, except much more lightweight--it happens in the natural flow of working on a file. This is just one example of many very productive features.
Another great example is rgrep. This command lets you search through files in a directory. However, the really cool thing is how it displays the results: you get the filename and the line where the match happened. You can go to the file directly or actually edit it in place in the rgrep results buffer! It's very nice for certain tasks.
Really, Emacs is full of incredibly well thought-out productivity boosters for everything you will do while managing software.
Moreover, it is not limited to language agnostic things. If your want Eclipse-like Java support, you can have it with eclim, which actually uses Eclipse as its backend. I also know of great IDE-like support not based on Eclipse for all sorts of languages from Python through OCaml.
Now, Emacs does have a learning curve. It will take a bit of effort to get good with it. It will probably require changing your entire workflow to take advantage of all the awesomeness. But it's more than worth the time investment: getting comfortable with Emacs is an O(1) action where the benefits it confers are a significant O(n) (if not better!) bonus. The more you program, the more you'll gain.
Learning Emacs gives you significant gains even if most of your job involves browsing around and editing existing code.
[+] [-] benjaminwootton|13 years ago|reply
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|reply
[+] [-] davidw|13 years ago|reply
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|13 years ago|reply
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/
[+] [-] qu4z-2|13 years ago|reply
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.
[+] [-] keithpeter|13 years ago|reply
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|13 years ago|reply
[+] [-] drothlis|13 years ago|reply
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
[+] [-] phektus|13 years ago|reply
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|13 years ago|reply
http://blog.vivekhaldar.com/post/3996068979/the-levels-of-em...
http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps...
[+] [-] masklinn|13 years ago|reply
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.
[+] [-] gnosis|13 years ago|reply
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.
[+] [-] aerique|13 years ago|reply
Vi(m) will be there.
[+] [-] Derbasti|13 years ago|reply
[+] [-] rjzzleep|13 years ago|reply
EDIT: gnosis mentioned why https://news.ycombinator.com/item?id=5730714 . i've only come across those cases a handful of times though
[+] [-] binderbizingdos|13 years ago|reply
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.
[+] [-] dysoco|13 years ago|reply
[+] [-] terhechte|13 years ago|reply
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
[+] [-] manish_gill|13 years ago|reply
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
[+] [-] tikhonj|13 years ago|reply
I think the final result looks rather good: http://jelv.is/emacs-blackboard.png and http://jelv.is/emacs-demo.png.
[+] [-] nieve|13 years ago|reply
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...
[+] [-] olgeni|13 years ago|reply
I thought pretty much the same, until I recompiled it using Athena widgets, which brought it back to its intended glory.
[+] [-] alexott|13 years ago|reply
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)
[+] [-] gexla|13 years ago|reply
[+] [-] tephra|13 years ago|reply
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)
[+] [-] derengel|13 years ago|reply
[+] [-] brudgers|13 years ago|reply
The power of Emacs is being command driven. The command for moving to previous line is:
The mini-buffer is where one enters commands. The command for switching focus to the mini-buffer is: Tell the new user what is really going on. To move to the previous line: a) enter the command <M-x> to switch focus to the mini-buffer b) enter the command <previous-line> to move the coursor c) after entering the command, focus will return from the mini-buffer to the invoking buffer.I don't have a hangup about calling <alt> "meta". New users already have somewhere to hang the mnemonic. On the other hand, until they have somewhere to hang <C-x p> it's not a mnemonic, it's just a weird way of doing stuff. In fact, giving the learner <previous-line> gives first, them somewhere to hang it.
What is typical of tutorials is that they jump past the well considered abstractions of the Emacs code, right into a set of customizations that made sense for the staff of MIT"s Artificial Intelligence Lab in 1979. These customizations were based on expertise with the software; the limitations of console interfaces with no drop-down menus, etc.; and most importantly many years to develop shortcuts on an ad hoc basis both for practical reasons and for the simple joy of productive laziness.
Perhaps <next-buffer> and <previous-buffer> are canonical illustrations of the way in which Emacs tutorials are more based on tribalism than pedagogy.
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.
[+] [-] keithpeter|13 years ago|reply
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'...
[+] [-] koalaman|13 years ago|reply
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.
[+] [-] drothlis|13 years ago|reply
† 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.
[+] [-] mattdawson|13 years ago|reply
[+] [-] throwaway1980|13 years ago|reply
[+] [-] Tloewald|13 years ago|reply
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.
[+] [-] lowglow|13 years ago|reply
[+] [-] erlkonig|13 years ago|reply
http://www.talisman.org/unix/img/editors/emacs-hints.png
http://www.talisman.org/unix/img/editors/vi-hints.png
[+] [-] astrobe_|13 years ago|reply
[+] [-] rbanffy|13 years ago|reply
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|13 years ago|reply
[+] [-] cbsmith|13 years ago|reply
[+] [-] sachac|13 years ago|reply
[+] [-] blumentopf|13 years ago|reply
Try M-% instead.
[+] [-] Lennu|13 years ago|reply
[+] [-] 6d0debc071|13 years ago|reply
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.
[+] [-] justinhj|13 years ago|reply
[+] [-] Derbasti|13 years ago|reply
[+] [-] nijk|13 years ago|reply
[deleted]
[+] [-] codex|13 years ago|reply
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|13 years ago|reply
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.