
Emacs isn't for everyone - twism
http://briancarper.net/blog/emacs-isnt-for-everyone
======
digitallogic
Any sufficiently complex system (whether it's a text editor, biological
ecosystem, or vehicle) is going to be difficult to interact with for a new
user. Emacs is hard to do, well anything, the first time you fire it up,
you're probably going to die in the Amazon if without a knowledgeable guide,
and you're not going to be able to sit down at the controls of a fighter jet
and just take off.

The trade of for this (is supposed to be) increased flexibility and power for
the person interacting with the system once they are familiar with it. You can
write elisp to automate tasks you do frequently, see animals in the rain
forest not found in zoos, and do maneuvers that can't be approached with a
Cessna.

Increased complexity of a system increases the possibilities for the user but
also increases the difficulty of acclimation. This is a part of life and not
specific to a text editor.

~~~
briansmith
> Any sufficiently complex system (whether it's a text editor, biological
> ecosystem, or vehicle) is going to be difficult to interact with for a new
> user.

Counterexamples: MS Visual Studio. MS Word 2010. MS Excel 2010.

~~~
simonista
I don't think those are completely valid counter examples. Sure you can fire
any one of them up and start using them for the most basic task for which
they're suited, but to really interact with them takes time and learning.

Just an anecdote: I work in a computer lab for these type of new users, and
after being trained for many years to go to a file menu, the round button that
serves as a menu access in Word 2010 trips a lot of people up. I get tons of
"Where's the print button?" questions.

~~~
bad_user
> _I don't think those are completely valid counter examples_

Yes they are ... "really interacting with them" is not their purpose.

You can open an Excel spreadsheet even if you haven't done so in your life and
only have experience using Word ... you can move around, search for text,
change styles, print. That's because it uses common interface elements that
have been used for years.

Yes, Office 2010 brings interface changes, but it's nothing to worry about ...
once you clicked the round button once, you'll learn its position. It took me
a whole week to not trip over C-x C-s in Emacs, or to remember C-x C-c, and I
had to setup my own shortcuts for common stuff (like C-w which deletes the
previous word ... as in Vim, because even if my life depended on it, I
couldn't learn the Emacs shortcut). And I still don't know how to print from
Emacs.

We are talking about technically-inclined people here. Textmate is a lot more
intuitive to use ... I'm still using Emacs because it is much more powerful,
but boy what a painful experience it was the first months.

~~~
eru
You can just use an Emacs that is displayed in an X-Window and use menus and
clicking. You do not have to rely on all the shortcuts.

~~~
nkassis
Yeah, my wife took a c++ class and that's what I showed her to use. She didn't
know any shortcuts but could move around and code with no problems using only
the arrow keys on the keyboard and the menus. (On a Ubuntu machine no less.)

~~~
eru
If you do not have a Unix machine, thanks to virtualization they are now easy
to set up without risking a heart attack in a normal user:

Just fire up a VirtualBox, and install Ubuntu in there. The hardest part about
a Linux installation is most often the partitioning--but you can just use the
whole virtual disk.

Or you just download a pre-installed image of a VM.

------
arthur_debert
The problem is that today, getting started often means: correct syntax
highlighting, indentation, auto-complete (intelisense), build integration and
scm integration. And for a few languages at least(e.g javascript, python,
ruby, html, css, xml, shell scripts).

This is the problem. Going through the emacs tutorial is not enough. It's not
that people have trouble getting started, they just don't want to experience
the sudden drop in productivity once those things go away (at least for a
while until you learn how to do them).

I've switched to emacs lately, and it was worth it. But it's hard to justify,
to a newcomer, why the default javascript mode sucks with common idioms (no
indentation, tags - and let's not even get started on intelisense).

When emacs and vi were kings, very few environments where that capable. So all
you had to learn was basic editing. Everything else was a surplus. In the last
few years, with the rise of eclipse, visual studio, netbeans and others, it's
a harder battle.

In my dream world the emacs community would do a gentle fork, that would have
ide like capabilities for common setups (python, js, ruby, c, perl, html,
java, etc) + editing as expected (like hungry-delete) + more common key
bindings (like the command key as meta on mac). Bonus point for a
s/frame/window/ , s/buffer/file/ and so on on the documentation.

This way, newbies would be almost at home from the start (some commands to
learn, plus the odd keybindings). But with time, they would customize more,
and learn to drop the training wheels if necessary. The problem is learning
everything at once (terminology, key bindings, elisp, editing) is too much
burden for most folks.

~~~
jseliger
_In my dream world the emacs community would do a gentle fork, that would have
ide like capabilities for common setups (python, js, ruby, c, perl, html,
java, etc) + editing as expected (like hungry-delete) + more common key
bindings (like the command key as meta on mac). Bonus point for a
s/frame/window/ , s/buffer/file/ and so on on the documentation._

This, by the way, is why I tend to use Textmate for the (very) minor
programming-related stuff I do on OS X: the bundles make it exceedingly easy
to do stuff fast.

------
ihodes
It seems to me as though people aren't reading the whole post.

Brian loves Emacs (and Vim), and will continue to use them for developing in
Clojure.

Right now much of the Clojure user base is rather avant-garde, but if we want
newcomers to the language, it needs to be easier to get into.

Setting up a development environment can be a pain in the ass for the
experienced user; imagine the impossible hell it could be for the newbie.

I think that's his point: it's a little more complex than "emacs is hard".

~~~
devonrt
I can attest to the fact that setting up a Clojure/Emacs/Slime/Leiningen
environment is a huge PITA. Something like Clojure Box helps, but it
sacrifices flexibility in favor of ease of use and hides a lot of underlying
configuration from a new user. A big part of the problem is a lack of a
"canonical" setup; if you Google around for Clojure and Slime most directions
you find will be out of date, highly personalized, or both. They will probably
involve checking projects out of a multitude of repos (be they CVS, SVN, or
Joe Blow's GitHub branch) and copying mystifying emacs configuration without
really understanding what it all does. And then, after all of that, it still
might not work. God help you if you want to get it all to work under Windows.

Don't get me wrong, I love Clojure and I... well, I don't hate Emacs, but it's
frustrating to have to deal with a lot of setup when one just wants to hack in
a new language.

~~~
gcv
swank-clojure 1.2.0 made the setup process much less painful. Yes, you still
need to install Leiningen and Emacs manually. After that, (1) an experienced
Emacs user can install clojure-mode and SLIME manually, or (2) anyone can use
ELPA to install those two modes. Those are fairly easy tasks, and don't
require much tweaking.

swank-clojure 1.2.0, which was always the hardest part, does not need to be
installed manually. It just gets listed as a dependency in project.clj, and
after that "lein swank" on the command line does magic.

~~~
devonrt
The process has gotten a lot easier and Leiningen has made things _way_
easier. lein-swank is just dreamy and comes close to providing all that nifty
class-path handling functionality that something like Eclipse provides for
Java. A lot of great work has gone into things like swank-clojure and
Leiningen and it's amazing that the Clojure community has pulled together such
a great set of tools in such a short period of time. There are languages on
the JVM _cough_ Scala _cough_ that have been around for a lot longer and
really seem to be lagging behind in terms of tools.

------
samatman
The best thing Clojure could do for widespread adoption, IMHO, is to build a
Clojure native IDE, extended from the NetBeans Enclojure plugins and REPL.

This would provide neatly for the programme suggested here:

[http://muckandbrass.com/web/display/~cemerick/The+Ideal+Cloj...](http://muckandbrass.com/web/display/~cemerick/The+Ideal+Clojure+Development+Environment)

A language like Clojure deserves an IDE which is extensible in the native
idiom. Building one, with the explicit intention of making it _the_
environment for learning and using Clojure, would do more for adoption than
any other single move.

------
maximilian
One thing that always gets me about blog posts like these, is that they never
fill in the details in the post. He goes on about things he's struggled with,
solutions he's found, etc, but never actually says what they are. I'm an Emacs
novice, and I love to get little tips from articles like this one, but so
often they just allude to it all.

~~~
Xurinos
That is interesting... When I read the post, I understood his references,
having had similar experiences. Now that you mention it, you are right: the
audience of this post is not the new users. It is the people who are trying to
push emacs as Clojure's choice development environment.

As a vim user, I am definitely open to good vim environment options for my
lisp experiences. My attempts to use current solutions have so far been poor,
for what it's worth; every solution seems frail, to break when I use just the
wrong key. Suddenly vim is screaming at me, and some background process that
handled the connection to a lisp has died or is unreachable by vim.

I use slime.vim (yay for vim and screen), but there is something to be said
for being able to have what amounts to intellisense for dynamically declared
functions, to have the experience of working actively with symbols within
packages.

As the author of the article points out, the key sequences for working with
lisp are ugly (long). And I would point out that in emacs, almost all key
sequences are ugly.

~~~
reflexer
I've found slimv.vim not bad for CL after all
<http://www.vim.org/scripts/script.php?script_id=2531>

~~~
Xurinos
I wanted to update you, since you were so kind as to give me a good possible
solution. I tried slimv.vim, and the experience is fairly decent. However, I
quickly ran into annoyances and problems.

I get a welcome message in the evaluation buffer that confused me for a while
because I thought I needed to position my cursor next to the asterisk (my
current sbcl default). It turns out my cursor needed to be at the end of the
buffer in order for my evaluated command to be recognized. Then the asterisk
prompt makes sense again. Growing pains, but this is a silly and easy thing to
avoid for new users.

I tried tossing in an easy form in a slimv-enabled buffer: "4". I ,e it, and
now I am stuck in the eval buffer where my 4 was evaluated as 4. How do I get
out? Ctrl-W Ctrl-W isn't doing the trick. After some messing around, I
eventually figure out with consistency that I have to hit SOME key, like
ENTER, in order to be "released" from the RUNNING state to switch buffers back
to where I was editing. ESC is no help here, although you would expect it to
exit a RUNNING mode in vim. I do not see any configuration to prevent me from
being forced into the eval buffer, so I am stuck with this disruption to the
workflow.

I could not figure out how to cleanly quit out of vim and shutdown slimv,
aside from issuing a (quit) and hitting ENTER a bunch of times in the slimv
window. The less clean Alt-F4 works as well.

I did a fresh installation of hunchentoot and all dependent packages from
within my vim session. This turns out to be annoying in that some of those
packages are so spammy that the buffer gives up refreshing (partly because it
is so slow to display all the new scrolling text). ,z refreshes the buffer,
assuming I am aware enough that it has given up and is not just pausing to
calculate something.

But the final kicker for me... The omnicompletion is both superficial and
poor. It is superficial because it only supports common lisp symbols, not
symbols actually in my current lisp environment. It does not support package
prefixes either, so I cannot complete on any of the sbcl packages, much less
anything I have installed. The linedit package does a super job of getting
this right, and slimv could do it right with a little help from with-package-
iterator instead of faking it.

The omnicompletion is poor, even with the basic common lisp symbols, because
"-" is not recognized as part of a word, so I am unable to omnicomplete forms
outside of the first few letters. I am, however, able to use basic Ctrl-N/P
autocompletion successfully in my lisp buffers with any symbols that include
"-", so I am confident my vim is configured properly somewhere. Am I missing
something to tell omnicompletion to recognize "-" as a word character?

Basically, I feel like with slimv I get sluggish and fewer useful features
than just using slime.vim. I really wanted some nice integration where I could
have the slime experience of being within the lisp environment, able to
introspect and so forth.

The bundled paredit is decent for its bracket handling; that is something that
will probably take me a lot of time to get used to. I have one significant
complaint about it, though. It is great that when I type a closing parenthesis
that the cursor moves beyond the already-provided parenthesis. It is much less
great that when I type a closing double-quote, it adds a new pair - and good
luck trying to delete one of the double-quotes once the pair is involved. It
is even worse that I cannot toss in an escape on the double-quote within my
string (try it! Can you type: "\"" ?). This makes the bundled paredit pretty
unusable, far more annoying than just leaving it disabled.

Is slimv even actually using slime? I saw the port configuration, but I really
get the feel that we are just repeatedly reloading a tmp file in a buffer, and
our hotkeys send direct lisp commands to an sbcl process wrapped by a python
script.

Taking a step back, I keep asking myself if this is all just whining.
slime.vim (which is not slime either -- it should be called screen.vim or
something) and linedit work well enough for me, given that they actually work
as advertised.

The other option for me is to just use emacs, but I cringe when I consider it;
I have been down that road, and it felt like somebody intentionally made it
difficult to actually do text editing in it.

Thanks again for the slimv suggestion.

------
docgnome
I realize it's a flawed analogy, but the thing about learning emacs is that it
isn't learning a single tool. It's learning the toolbox you can use to build
the wood shop. The toolbox that keeps getting bigger and bigger. It's been
years since I "learned" emacs and I'm constantly learning new things. If you
go into it expecting instant gratification, you're gonna be dissapointed. That
said, I've still never gotten CEDET "intellisense" thing to work in anything
other than C++. And that's part of emacs now!

~~~
delackner
This was the dealbreaker for me when I last tried to pick up Emacs (albeit at
this point that is about 8-9 years ago) there was just nothing at all that
could compare to intellisense, for any language.

How's that going today? XCode has fantastic intellisense for C and Objective-C
along with jump to declaration / jump to definition.

~~~
docgnome
Every once and a while I try to set it up, but I also don't really care that
much. I've gotten it to work great for C++ but haven't really bothered with
anything else.

------
jluxenberg
_"But how long is it going to take you to figure out that tab-completion is
called hippie-expand in Emacs?"_

I figured he must be joking, so I alt-tabed over to my Emacs session. To my
surprise, there is actually a command called hippie-expand in Emacs!

------
avar
I still remember learning Emacs for the first time, it was easy, Just time
consuming.

Sure I'm still learning it (that's the nature of Emacs), but getting started
is easy. Just read the tutorial to get a grasp of the basic commands and
concepts, and as soon as you read about the built-in help system you're good
to go.

If you don't know what a key does you just prefix it with do `C-h k` to get
help. If you can't recall the keybindings do `C-h b`, and if you've forgotten
all of this do `C-h ?`. The entire manual is just a `C-h r` away.

The built-in documentation makes it really easy to learn more, it just takes
patience.

~~~
silentbicycle
The trick with using the help system is that Emacs uses very different
terminology than many people expect. (He touches upon this in the article.)
You get used to it, eventually, but it does add extra work upfront.

The easiest way for me to pick up the terminology was to skim through the info
page for Emacs (C-h i takes you to the info pages). After that, apropos became
quite a bit more useful.

------
reader5000
His point is correct. There are better time investments than the editor. It
actually took me a while to get into clojure because of editor issues.
Eventually I settled on notepad++ (which unfortunately does not yet support
clojure syntax highlighting; I use its lisp option) and the commandline. Works
well enough for my purposes.

~~~
kiba
Well, emacs is not just another _text editor_ , it's a whole operating system.
The ability to port your emacs skills to other uses, such as reading emails,
IRCing, and organizing means emacs is a powerful force multiplier.

You don't have to learn emacs for hours each day. You could do ten minute
learning each day tops. Scrap together a few editing shortcut there and there,
learning a new feature of emacs, add a new a program, and practicing your
editing your skills.

All of these will eventually add up. By the time you're an old fart(Says 50
years old), you could laugh at children with the new fanged badly reinvented
versions of emacs and their slow-ass editing workflow.

However, I am just 19 years old who get a little bit of thrill every time he
spend a fraction of time each day learning emacs and optimizing his workflow.
I got ways before I accumulated several unusual but extremely efficient
habits.(Batch web browsing anyone?)

------
donaq
I don't really understand the fuss. You can edit Clojure with any text editor,
right? Syntax highlighting, auto-complete, auto-indent, etc are nice features
to have, and I do use them, but not really necessary for learning a
_language_. If the language is interesting, I will learn to edit it in vim
regardless of whether it's well supported.

Then again, I am probably not a good sample, since I eschewed Eclipse for
notepad back when I was learning Java before I discovered linux and vim.
Regardless, I still hold the opinion that it is a good mental exercise to
occasionally hack the raw text without all the bells and whistles of an
advanced text editor/IDE in order to internalize the language structure.

------
grandalf
I've been pleasantly shocked at how helpful the people in #emacs have been.
Thank you!

------
mattrepl
There was an article a few years ago on how the time investment of learning
new programming tools is often worthwhile. I believe awk was included as an
example.

Anyone recall it?

~~~
dpritchett
It's usually easier to learn one new thing at a time. If you're a C#
programmer interested in Clojure, you need to consider transitioning from
Windows to Linux, Imperative OO to FP, .NET to Java, and Visual Studio to
Emacs/Vim/Eclipse/Netbeans all at once.

I'm reading books on both F# and Clojure in an effort to get comfortable with
functional programming. Plenty of it is sticking but the Clojure toolchain
occupies a lot more of my mental bandwidth than the F# toolchain since I can
work comfortably in Visual Studio.

I am learning on all of these fronts simultaneously but it still detracts from
my ability to isolate Clojure and learn it without additional effort: I run
Windows on a daily basis but I play in Ubuntu VMs regularly to facilitate my
programming exploration. I am happiest in Notepad++ but I've recently learned
Vim to help me code in Linux. I am honestly not particularly familiar with the
ins and outs of .NET but Java is a completely new world to me, particularly
the build system.

------
bonsaitree
NS. Emacs shouldn't be anyone's first text editor, but if experience is any
guide, it will be many's last text editor.

------
ericb
Is there a decent editor I can extend using ruby?

I keep trying to tackle emacs or vim and getting thwarted. I'm not fully
convinced they're what I want, and I feel like I won't know until I spend a
year learning one, and by then I'll be wondering if I like it because it is
awesome or because I have Stockholm syndrome.

~~~
iron_ball
Not with Ruby, but I recommend jEdit -- it has 80% of the power of emacs/vi
with 20% of the learning curve, and you can write macros and plugins in
Beanshell, a lightweight scripting language that feels somewhere between Java
and JavaScript. Though honestly I've never even needed to -- the built-in
commands, easily-recordable macros, and decent plugin selection have always
done the job.

~~~
fakeempire
80% of the power? You're missing the point.

magit, org, dired, killring, ido, mingus, tramp, (can jedit use pyflakes or
similar), shell, term, gnus, vcs-mode, etc etc etc.

the only thing i have to leave emacs for is a decent browser. pretty sure
jedit couldn't provide me with the same. and i just do python programming.
million more modes for different tasks?

~~~
iron_ball
jEdit has 80% of emacs's text editing power. It does have a kill ring,
registers, marks, etc, because those are all text editing features.

Its file browser pane handles most dired-type stuff. Shell/console, ssh,
version control, transparent FTP in the file browser, all available as
plugins. There's a plugin to open files and switch buffers in an increment-
search fashion, like ido.

There's no pyflakes integration, but there are lint plugins that interface
with the error list, so a pyflakes one shouldn't be hard to hand-roll. If
solving your own problems with elisp is a virtue, so is solving your own
problems with Beanshell.

In jEdit, a "mode" is just a syntax highlighting scheme, but a plugin can set
up special behaviors to deal with certain file types -- just like an emacs
mode. Major and minor modes are possible, though not with those names.

There's no mingus. That's a text editor function? Ditto org; there are more
focused apps for that. There are newsreaders, though I don't know why.

So the answer is, yes, jEdit can do most of that. However, I understand that
if you're very accustomed to emacs, an emacs-style interface to daily tasks is
better than whatever a standalone app might have. If so, that's fine; but
don't accuse me of missing the point. We just have different points. I want a
_really good_ text editor; if it does other stuff, great. jEdit is a really
good text editor.

~~~
fakeempire
Emacs isn't a good text editor. vi is a far superior text editor if you want
to only edit text. But thats the point, people that _really_ use emacs dont
just edit text in it. They live in it.

Your filebrowser pane isnt the same. In emacs dired is an actual buffers that
you act on in the same way you act on other buffers, same with magit (this is
the best interface to VC i've ever used), same with mingus (front end for mpd,
btw) and every other mode.

So thats where our communication breaks down. Emacs isnt a good text editor.
The entire emacs environment is where the value is. If you just want to make
edits on files, use vi. its faster than anything to do that (I used vi
exclusively for over a decade). I know jedit is nice too.

But if you spend 8 hours a day programming then the value of emacs can shine.
And the real point is, if you spend that much time programming then its silly
to worry about the initial learning curve. Who cares about that time, it will
be paid back infinitely over your career.

But as always, its a useless debate. You can't understand the value of
something until you actually use it. That goes for both of us, I'm not just
taking a snipe at you.

~~~
iron_ball
Perhaps I'm missing a nuance, but I think what you're saying is that you
prefer to use the overall emacs workflow for all your tasks -- emacs as OS,
UI, and human interface guidelines all in one. I find no fault in that! And
who knows, if I took the time to master emacs, maybe I'd prefer it as well.

------
edanm
When I decided to learn Lisp a few years ago, I realized that I had to learn
Emacs (something I'd wanted to do for a while anyways). I ended up messing
around with Emacs for a few months, and never did learn Lisp.

And that perfectly sums up, for me, the problem with Emacs. It's a great
editor, and it's loads of fun to mess around with it and learn it. But at the
end of the day, when I actually want to get stuff done, it tends to get in the
way more than it helps, so I always end up going for another editor.

------
Ben65
I think since Clojure is a lisp there will always be a lot of people using
Emacs to develop it. Emacs itself is an outstanding lisp environment, too bad
the editor is so quirky. :)

Yes it takes some time learning, but it is worth it, if you like lisp
programming.

PLT Scheme is a great environment, yet there are people who would rather use
Emacs. I guess once you conquer the beast you it's hard to get away from it.

------
rbanffy
As for installing Slime, Clojure and swank, I love ELPA

<http://tromey.com/elpa/>

Very easy, almost single step.

A Leiningen hook seems absent, however. But I never really used Clojure for
anything serious.

------
gfodor
Note that his original reason for learning emacs, namely, that there's not a
good Clojure REPL for Vim, is no longer true.

<http://www.youtube.com/watch?v=rqweCwAMan0>
<http://kotka.de/projects/clojure/vimclojure.html> Works great, no paredit
mode tho.

And then theres this one, which I haven't used:

<http://www.vim.org/scripts/script.php?script_id=2531>

~~~
dpritchett
VimClojure is fine until you want to play with something linked against a
1.2.x version of Clojure. Then VimClojure falls down and you have to fall back
to emacs (or a standalone REPL) for compatibility.

[http://groups.google.com/group/clojure/browse_thread/thread/...](http://groups.google.com/group/clojure/browse_thread/thread/7cec825282f22f90/070187e959cd1648?hl=en&lnk=gst&q=vimclojure+1.2#070187e959cd1648)

The next major release of VimClojure should solve this dependability issue but
it doesn't seem to be a high priority to its maintainer (last release was
nearly a year ago).

------
icey
Here's what I don't get: People don't seem to have any problems with learning
entirely new programming languages every year, but if you ask them to learn a
new editor they get up in arms about it.

I think if people spent half the effort on learning emacs as they do learning
the languages that emacs works well with (lisps, mainly) they'd pick it up
just fine.

(I'm not advocating forcing anyone to use emacs, fortunately there are a lot
of other options. I just don't get the hand-wringing around saying it works
the best for a given language.)

~~~
cemerick
The language I use to build software with is _precious_ to me. It's
capabilities are often key to what I can do, how I can express myself.

The editor I use to write code is a commodity. Will switching to emacs help me
write better software? Solve harder problems? No, it'll help me sling text
faster -- which, unless you're doing fairly pedestrian things, is the least
interesting, least common thing you should be doing each day.

~~~
sanderjd
It isn't really about slinging text faster, it is about _editing code_ faster,
freeing up more cycles for thinking. A great editor experience, whatever that
means for you, can certainly help you write better software, and can give you
more time to think about those harder problems. It reminds me of that tired
old adage that you spend a third of your life asleep so you should have a
comfy bed - you spend a lot of time in your editor, so it should be comfy.
This isn't an argument _for_ emacs or any other specific editor, but _against_
the idea that your editor is a commodity not worth consideration.

~~~
cemerick
Commodities are worth consideration, just not maximal optimization when there
are switching costs involved. My core point was, editing code isn't the
bottleneck in building quality software efficiently, so optimizing that
process beyond a certain point is premature and wasteful.

------
lelele
Worst thing about learning Emacs is that newbies follow the wrong path, albeit
you can't criticize them for not knowing better. Absolute newbies should start
with an Emacs customized to follow common conventions of editors (CUA, etc.);
Vi users should start with Viper mode (+ Vimpulse). And so on.

~~~
jrockway
I disagree completely. New users should follow the tutorial. Eventually, to
use Emacs as Emacs, you are going to have to understand its model and its
terminology. Pretending that doesn't exist until you have learned how to use
Emacs as a very bloated Notepad clone will leave you thinking that Emacs is a
very bloated Notepad clone.

I learned Emacs when I was in middle school. If I could figure it out then,
from the interactive docs, any adult should be able to figure it out. If they
don't want to, though, that's a whole other issue entirely, and is not
something software can solve. Emacs is different. Learn it or don't.

Now, once you understand Emacs, then sure, use Viper. It's a great tool. But
if you don't understand Emacs, then Viper is just going to make you mad. (No
experienced Emacs user would use the CUA keybindings, though.)

~~~
lelele
Come on, Ctrl+ZXCV are so ingrained into the fingers of people who type a lot
that having to learn a whole new set of shortcuts does not seem an efficient
route. You are not likely to keep them, anyway (since it's way easier to
customize Emacs to a common set than other apps). I remember resorting to use
my mouse almost always. Nowadays, after having customized Emacs, I'm a
keyboard junkie.

~~~
jrockway
Everyone? I use Shift-Insert to paste in Windows. I forget that C-v is "paste"
in Windows, and get upset when it pastes instead of scrolls.

------
suraj
I was trying out racket yesterday and I couldn't figure out how to get the
previous line in DrRacket. I tried all sorts of combinations and finally
pursuing documentation came up with Esc-P shortcut. You can argue that this
feature was first implemented in scheme before arrow keys were there but
looking at it now it is different than everything else.

For me switching from Windows to OS X was easier (just use Command instead of
Ctrl) than switching from "a generic editor" to emacs/vim. The point here is
not that learning emacs is hard but that there are now a significant number of
developers who expect standard shortcuts from the programs they use.

~~~
soegaard
Hi Suraj,

Consider filing a feature request. Once upon a time you could use ctrl+uparrow
to get the previous expression in the interaction windows. I don't know, why
that keybinding disappeared. Perhaps it was just an oversight?

~~~
suraj
Soegaard, I was thinking of submitting a patch over the weekend. That way I
get to see how a large lisp app is designed :)

------
grogers
I can understand that interacting with the REPL inside an emacs session might
be better than what you can get in vim (haven't tried either yet - I just use
a separate REPL session). But is there anything particular about emacs the
editor that makes it particularly good for editing lisp code? For example, the
text object selection in vim (:help object-select) has been great for
interacting with paired () [], auto-indenting blocks, etc.

------
JulianMorrison
"lein repl" and gedit open in another window. These complicated Clojure setups
with slime and so forth are unnecessary.

------
TheBurningOr
Good timing on this Tweet. I had just downloaded Emacs with the hope of trying
it out as a Notepad++ replacement. Think I'll save it for when I have more
time to play around with it.

~~~
Naga
It is worth it. It takes time, but it really is worth it.

------
ahk
Yup. And what's the deal with it not having an horizontal scroll bar?

------
c00p3r
First of all: Emacs (and vim) are perfectly usable on (and originally
developed for) a dumb terminal, or so-called console. This is the main
difference with modern IDEs such as eclipse, and Gnome or KDE-based ones.

The key-sequences in vi (the true masterpiece) and long sequences in emacs are
designed and evolved to be useful on terminals, and they definitely are.

Vim and emacs both were text editors based on original concepts and then
evolved as source code editors, rather than IDEs which were created to imitate
Visual studio. =)

------
erlanger

      > It is however extremely painful to learn.
    

I can attest to that, physically.

------
napierzaza
Really? But everyone uses it right?

------
programnature
amen

