
How to Learn Emacs: A Hand-drawn One-pager for Beginners - alexott
http://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand-drawn-one-pager-for-beginners/
======
benjaminwootton
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[http://blog.vivekhaldar.com/post/3996068979/the-levels-of-
em...](http://blog.vivekhaldar.com/post/3996068979/the-levels-of-emacs-
proficiency)

[http://my.opera.com/mulander/blog/2009/02/17/how-emacs-
keeps...](http://my.opera.com/mulander/blog/2009/02/17/how-emacs-keeps-
replacing-my-tools-at-work)

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

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

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

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

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

~~~
manish_gill
My GVim: <http://i.imgur.com/5nH37zy.png>

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

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

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

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

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

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

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

<http://www.emacswiki.org/emacs/UndoTree>

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

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

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

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

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

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

~~~
xaritas
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)

~~~
quiesce
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>

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

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

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

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

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

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

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

~~~
sachac
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
> 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
I thought we got over editor flamewars ten years ago?

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

~~~
cbsmith
> 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.
;-)

------
blumentopf
"M-x replace-string RET"

Try M-% instead.

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

~~~
6d0debc071
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.

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

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

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

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

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

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

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

