Emacs isn't for everyone
briancarper.net
briancarper.net
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.
Here's my latest (failed) attempt to get VimClojure working with Clojure 1.2 (search for dpritchett): http://clojure-log.n01se.net/date/2010-05-13.html
I am new to REPLs and to Java-based development and to emacs. When I read about the magic of the REPL's positive feedback loop it's easy for me to think that all of the pieces are equally valuable.
It's been a few months now and I can see how just copying and pasting from vim into a standalone REPL wouldn't be a horrible way to go about building something.
P.S. - Loved your enlive demo! Thank you for one of the best Clojure examples I've read.
The out-of-the-box repl experience on Clojure is really bad. In fact, it's so bad that one begins to suspect it's bad on purpose in order to encourage new users to get their editor integration working sooner rather than later.
Counterexamples: MS Visual Studio. MS Word 2010. MS Excel 2010.
Office is a much better example in my experience, particularly Excel.
In contrast, I still don't know how to do "Go to Definition" in Emacs; in fact, I don't even know how to tell Emacs how to find all the source files for a project. I doubt I would have been able to complete the same task in the first day I'd used Emacs.
Emacs can be used as an IDE. I use it every day that way. I can use it like that because it's completely programmable. When I needed a Pyccuracy-specific editor, it took me an afternoon to write one (not from scratch) in Emacs-Lisp. I could probably have a spreadsheet inside it, if I really wanted.
Try to build a Lisp IDE inside Excel... ;-)
About the "go to definition" thing, it depends on what major/minor mode you are using. There is probably something like that for C-ish development. I just never used it.
And for finding all files in a project, there must be something that parses makefiles and rounds up source files. Emacs is older than many of us and someone must have already solved this specific problem in the past 40 years.
I am playing with "nav" in order to build special-purpose browsers. I would love to have a YQL-mode, but I feel I should replicate the multi-pane tool Yahoo makes availabe.
The way you interact with Emacs is through a text editor.
"The first time I used Emacs I found all kinds of Lisp functions I already knew. It has a familiar grep command that lets me click on results to jump right to each matching line in a set of files. I used the online help to find a command that evaluates Lisp expressions immediately allowing me to extend my environment just like typing into a REPL. ..."
You probably get the idea.
I mostly do C/C++ stuff. I use gnu global for code tagging and navigation [1](aka "goto definition" thing). As for project organization, I have no experience but you might want to check out CEDET [2]. It appears that CEDET has made it into emacs trunk, so hopefully you can get some nicer "project" stuff in emacs soon.
You might try "definition", but the hits for that aren't programming-related (emacs has a much wider scope of functionality than Visual Studio), so you'd probably go up to the top level of the manual. One of the topics there is "Features for maintaining large programs". That would tell you exactly what you want.
In your example you talk about "shortcuts of every other program on my computer". So you're assuming a programmer comfortable with windows. If I take the same liberty and assume a programmer comfortable with Unix, s/he will look in the Tools menu, see "Search Files (Grep)" and have immediate success finding the definition without any use of the emacs help system.
(No, I don't personally care. I don't use Word.)
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.
Each cycle, Microsoft does usability tests with new users doing moderately complex stuff. One of their designers did a series of blog posts and videos about their approach to usability and usability testing for Office 2007 that was really interesting. The whole point of the Ribbon UI for Office 2007 and later was to make it easier for users to discover and use the advanced features of Office without training.
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.
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.
But dig any deeper into the build system and you will quickly realize that the editor is the easy part of the job. You mistake the whole job for the easy part. Visual Studio (and Word, and Excel) are enormous tools with vast functionality.
Yes, I am an Emacs user. Today I decided to add two more mouse gesture bindings to my init.el - scroll-wheel action when the pointer is in the mode line - in addition to the bunch I already have that make my life easier. And the kind of Lisp you have to master to do that is material for a 5 minute tutorial - in the end, two lines were added to the init.el file. They are very easy to understand, BTW:
(global-set-key [mode-line mouse-4] 'next-buffer)
(global-set-key [mode-line mouse-5] 'previous-buffer)Most probably, they will start with a book or something like that to learn the basics.
My point is that with a single download (and no real installation besides a single click), you can get a new environment up and running in Visual Studio.
I'm not saying VS is the world's greatest IDE (I use it strictly for .NET work, and use gVIM for everything else--and use, I've used emacs, too). I'm merely talking about it in the context of the ease of integrating new languages/frameworks.
There may be some minor counterexamples, but overall, Visual Studio is a _vastly_ superior development experience (for C++) than any other environment.
I'll take the "you have to know what you are doing" route any day.
This attitude of "to drive a car well you have to be a mechanical engineer!" is dangerous to efficiency. As is the Stockholm syndrome that so many make users seem to be suffering from. The difference between the two is that with Visual Studio, you can defer learning about the build system in depth until the moment that you actually need it, whereas with make you need to spend a whole of time upfront, for no discernible gain. I'll take a 'easy things are easy, hard things possible' approach any day.
I think a human being qualifies as a complex biological system. Oddly enough, I think a new user would rather interact with to a human than a cricket, a mouse trap or an old DOS machine (to name some simpler systems).
Indeed, humans are rather clearly adapted to interact with other humans. So it's clearly possible to systems which are both extremely powerful and very easy to "use". We human clearly aren't yet at the point of easily constructing artifacts with this combination of power and usability but we shouldn't take that as proof of anything but our inability.
I'd be _really_ interested in a .emacs with enough balls to break completely with tradition, even if it would sacrifice some of the most used current shortcuts. My meager attempts made it a lot easier in the beginning, because I could at least use instinctive shortcuts for save/load/compile etc. But I cheated: I used the old Borland standard (F2 save F3 load F9 compile). For the real deal you'd have to do something about the all-mighty C- shortcuts.
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.
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.
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".
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.
I can't. apt-get install emacs slime sbcl. emacs. M-x slime. Hack away.
edit to add: How does one even know to install SBCL and hit M-x and type slime to get started? You and I might already know these things, but it doesn't really help a stone-cold newbie, they still need a more concrete starting point.
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.
caveat: github was being weird and i couldnt clone the repo so i had to visit the downloads page and get it to package up a snapshot for me.
anyways, its the least painful experience setting up emacs ive had. ymmv?
"I strongly believe that when it comes to computers, there's no such thing as 'intuitive'. There's stuff you've already spent a lot of time getting used to, and there's stuff you haven't."
I'll assume that idea serves him well. It's just clearly false. Some environment are inherently more intuitive than others. A GUI is earier to deal with than an unresponsive terminal just Spanish is easier to learn than Chinese.
Html has been a blessing since it's stopped many programmers like him from having a hand in interface design.
I don't think you're making the point you want to here. Spanish is easier to learn than Chinese for English speakers, certainly, but it's not inherently more intuitive than Chinese. Spanish is easier to learn for English speakers because it is more similar to what they have already become familiar to. For a speaker of Japanese, Chinese is probably easier to learn than Spanish.
Presumably, Chinese is easier to learn for Japanese speakers for the same reasons of similarity and familiarity that speakers of English have towards Spanish. If Chinese is inherently difficult, perhaps the Japanese could cope with it better than English speakers, as they had already gone through the rigors of learning Japanese, a language with similar (if not the same) level of difficulty.
I could be reading too much into it, of course :)
This would provide neatly for the programme suggested here:
http://muckandbrass.com/web/display/~cemerick/The+Ideal+Cloj...
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.
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.
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.
1. Windows opening and closing seemingly at random when using SLIME 2. Horrible default fonts 3. Unfamiliar keybindings, some of which are awfully long keystrokes to do very common actions, e.g. C-x C-f to visit a file, C-x C-s to save a file. 4. Struggling with Emacs jargon and navigating the help system
There was a lot more. Part of the problem is that none of these things bother me any more, because I've drilled them into my brain over the past two years. So I don't remember everything I struggled with. I just remember being extremely frustrated.
For the most part I never found solutions other than getting used to the Emacs way of doing things, and changing my habits.
A (true) anecdote.
I use a piece of custom software at work. Parts of it are horrible to use, truly awful, unintuitive, time-wasting.
For those of us who've used it for a year or more we ignore the rough edges. We know that when you perform a certain action a pointless warning box appears so you immediately hit 'Enter' to dismiss it before it even appears. Obviously we know what the menu entries do, even the ones with no text label.
We were forced to use this software at a point where we couldn't fix it. Now we have the ability to fix it but we've changed our habits to fit it so we don't bother even filing bug reports. New users, however, are going completely crazy trying to learn it.
My opinion of emacs configurations[2] is that they are incredibly elaborate jenga towers; 30 or 40 odd years of scripts balanced with utmost care on top of each other. As i mentioned in a previous comment ive stopped trying to maintain my own clumsy pile of jenga blocks and have used technomancy's emacs-starter-kit. So far i'm happier than i've ever been with an emacs install[3].
so, in an attempt to avoid letting the success i had on monday evaporate.
0) grabbed a recent emacs 23 for mac os x (not aquamacs at various suggestions).
1) grab the emacs start kit; its targeted at dynamic languages in general, not just clojure. It is a replacement for your ~/.emacs.d/. It includes elpa, the package manager thing. M-x package[tab] will list all the functions in the package manager.
2) grab a cheat sheet and attach it to a surface near your screen. refer to it often.
3) i have not even tried to use slime and swank. emacs and paredit are enough of a learning curve for me at the moment. I use lein from the shell to access my repl, git from the shell for managing my repo.
4) install clojure-mode via elpa if you are dabbling in clojure. apparently its not part of the default starter kit. M-x package-install [enter] clojure-mode [enter] i believe.
I'm happy with his because im learning the keybindings for emacs and paredit without having to worry about futzing with the emacs setup. paredit is already proving to be a great mode for editing clojure (or lisp in general i guess) code that its improved my life vs textmate. maybe in 6 months i'll look at tinkering with things some more.
[1] I used emacs at uni for about 5 years, and later at a job for a couple. At no time was I happy with my emacs set up, merely content that it was working. [2] bound to be hated by those who are fluent emacsians; sorry guys its just how it looks from where im sitting. [3] I'd still be using textmate for clojure if i hadn't heard about paredit. Maybe when counter clockwise gets a bit more love i'll have another look at using eclipse for my clojure code.
[edited:formatting]
How's that going today? XCode has fantastic intellisense for C and Objective-C along with jump to declaration / jump to definition.
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!
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.
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.
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?)
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.
Anyone recall it?
Awk has a pretty high utility : time-to-learn ratio. It helps that the language is so small.
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.
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.
Emacs has handled them all with aplomb.
I can make a one-liner in ruby to do what I want as fast as I can make a macro, generally. Moving files and directories, find and replace with conditional logic, running cleanup scripts, after-update hooks, generated files. Those are just a couple of things I might use it for, and I'd like it in the IDE so I can just work out of there. The point of programming is that it lets me do anything.
For eg. In Perl there is big momentum behind Padre (http://padre.perlide.org/) and there are similar projects in Python (quick google shows Leo & Pyk).
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?
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.
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.
Also try Textmate. Can't be extended (directly) with Ruby but it does rely heavily on Unix shell for lots of its stuff (usually Ruby scripts).
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.
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.
Very easy, almost single step.
A Leiningen hook seems absent, however. But I never really used Clojure for anything serious.
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://groups.google.com/group/clojure/browse_thread/thread/...
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).
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.)
Ok, it's just font highlighting and indentation help, while a good Java IDE does much more (i.e. completion, refactoring), but still it's nice to have one editor that works reasonably well with everything you decide to throw at it. (And yes, editing Cython code without Cython- or at least Python-mode feels like you're missing a finger).
(b) is strange when you look at it - Eclipse's PyDev and NetBean's python support are in fact very decent IDEs for Python, but they force you to do everything the Eclipse (or Netbeans) way.
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.
It will HELP you write better software, yes. Solve harder problems? It will help you solve harder problems FASTER maybe.
Spending less time dealing with the program text is a great way to be able to spend more time thinking or tinkering. A good text editor facilitates this.
(And of course, Emacs is more than an editor.)
That's a huge opportunity cost, when I know I can get the job done efficiently using far more pleasant tools that I already know. Those that want to promote emacs need to come up with real, tangible benefits that I'll be able to realize that will reliably offset that cost and then some. Rainbow parens aren't going to cut it. (That's an honest challenge, FWIW, despite the seasoning of snark. ;-))
Example: I have an expensive keyboard imported from Japan. When I tell people about it (and let them try it), they order one immediately or they come up with some reason why they don't like it and then want to have an argument? But I don't care! I'm not in the business of selling keyboards, I'm just a happy user. Buy one, don't buy one, it's all the same with me.
Emacs is the same way. Everything I've needed in Emacs I've written myself. Other like-minded people have written other things I like. More users would mean more extensions, but it doesn't really matter, there are already enough. So if you want to use Notepad, knock yourself out. It's your life.
Like Clojure, it's a friendly parasite on the underlying platform. Both are part of my programming experience; and both are invisible for most of my software's users.
But I agree, Emacs is tough to learn (especially if there isn't other emacs user nearby) and is a barrier to entry for anything which depends on it. And the emacs experience could be much improved. I don't know why it hasn't been far exceeded in nearly all ways.
Of course, I'm not comparing emacs to vim, but to something like Word. I plan to learn vim in the next few months.
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.)
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.
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?
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. =)
> It is however extremely painful to learn.