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.
> 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.
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.
Yeah, that's why I picked 2010. In 2010 the File menu is no longer the round button like in 2007; it is labeled "File" again. And, it is pretty clever, especially regarding printing; print preview is build right into the print dialog box and updated in real time as you change options. It's already saved me time & paper.
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.
> 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.
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.)
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.
The Google system is immensely complex, involving thousands of machines distributed through several continents. Somehow I manage to interact with it by typing a few words...
I have used Visual Studio from 6 to 2005 and I never perceived it as simple. The editors may be easy to learn because they follow CUA conventions, as are the menus.
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:
True to a point, but come on - one has to admit that Visual Studio, overall, is vastly easier to use to develop software as the equivalent typical Unix environment. Setting project dependencies (linking with other libraries), for example, is after 30 years still a topic that make me want to stab myself in the eyes every time I need to (again) look up how to change the makefile. That is, if they're using make, which sucks but which most people use. But if they're using, oh, scons, or a custom one like boost, well good luck making _any_ changes to that without spending hours just getting up to speed.
There may be some minor counterexamples, but overall, Visual Studio is a _vastly_ superior development experience (for C++) than any other environment.
Visual Studio's "ease of use" may lead to developers who can't write a makefile (because they don't have to map dependencies), who don't really know (because they don't have to) what libraries the linker is linking the program against and who don't care if the build process is convoluted or fragile (when I had to develop in a team we had to standardize the full path - down to drive letter - we would put everything across all members of the team) because the IDE takes care of it (most of the time).
I'll take the "you have to know what you are doing" route any day.
Why is all of this bad? (except from your example which I don't understand but which sounds not good) Division of labor, remember? Why should we force all of this useless stuff onto each and every developer? If there is one guy on the team who knows how to fix issues with the project files and dependencies and whatever, the rest of the team can get on with their work instead of each and every one having to read man make every two weeks.
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've been in the same boat, using Visual Studio for a long time. I agree that VS is an enormous, and I don't use it to its full advantage. The original author's point was, however, that getting Clojure running under emacs is less than simple for a new developer. Contrast that Visual Studio. I install VS2010 with the C# extensions, but then I want to do some F# development. I go to the MS site, download the extension (or use the MSDN disc I have stashed in my desk), install it, and away I go.
But, you wouldn't have to download anything to develop F# with emacs, because caml-mode is already there. Also, as much as Slime and and whatnot add to Clojure development, you don't need them. The lisp modes and inferior-lisp repl that ship with emacs work pretty darn well.
You wouldn't have to download anything? You mean emacs comes stock with a F# compiler?
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.
His point appears to be VS is easier to use for people familiar to VS. If you have two developers equally unfamiliar to their respective development environments, VS and, say, ClojureBox (a Clojure+Emacs combo), their learning curves won't be that different.
Most probably, they will start with a book or something like that to learn the basics.
Those are not counterexamples. Any new user who could fire up those programs and do something useful could also fire up emacs and do something useful. Emacs does have menus at the top, you know.
Here's an example: I wanted to add TLS 1.1 support to NSS (Mozilla's security library). I downloaded the code, downloaded Visual Studio, and imported the source files into Visual Studio. Then, from the menu I was able to learn that F12 is "go to definition" and Ctrl+Alt+Shift is "go to declaration," which were huge time savers for navigating an unfamiliar codebase. All the other shortcuts I needed were the same as the shortcuts of every other program on my computer. Visual Studio also highlighted all kinds of syntactic and semantic errors in near real time as I edited the files, which saved me many compilation steps. And, it's updated-in-real-time autocomplete was a real time saver as well. As a result, I was able to complete the necessary changes to add TLS 1.1 support within hours of the first time I'd ever used Visual Studio.
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.
It's an apples to oranges comparison because Visual Studio is an IDE built for programming for Windows while Emacs is a text editor that can edit C++, Python, function as a Lisp IDE, edit org charts, browse the web, play music, read e-mail and typeset papers, among other things. It's, actually, a small OS built to emulate the OS Lisp machines ran.
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.
You are right on some fronts. It does require some work in Emacs to set up the ideal dev. environment.
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.
How many years of experience did you have using Windows before then? You had a lot of domain knowledge already whether you realize it or not.
"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. ..."
Suppose the first day you used emacs you faced that task. You would look in the menus: Help / Search Documentation / Look Up Subject in User Manual
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.
I say this as someone who has been working with MS technology for over a decade; once you get past the narrow confines of the sexy demo, VS is not all that friendly to the new user. This characteristic has always been one of my main gripes with VS. (Incidently, I often daydream about a parallel universe where instead of creating VS they decided to invest the same resources into emacs or vim.)
Office is a much better example in my experience, particularly Excel.
I agree. Visual Studio doesn't make everything easy. But, I was shocked at how productive I was at using it immediately after opening it for the first time.
Clojure's ecosystem is more tightly coupled with emacs than it has to be. In my experience if you want to use the bleeding edge Clojure jars and tools you're best off sticking to emacs. This is an extra training burden for anyone who just wants to poke around in a REPL with some code completion and syntax highlighting capability.
Sigh, Clojure isn't tied to Emacs at all. The problem is rather how many people are on the mailing list or IRC channel who can help you with your less popular setup. You could of course save yourself oodles of time by sticking with one of the IDEs which are positively simple to setup or just using your favorite text editor and a regular REPL.
Curiously it hadn't occurred to me to actually stick with a standalone REPL until I read Alex Miller's comment at the article suggesting just that.
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.
> Curiously it hadn't occurred to me to actually stick with a standalone REPL
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.
Both enclojure (for NetBeans) and counterclockwise (Eclipse) are solid environments that are being used full-time by a bunch of people. I've used the former for a long time, and am on the bleeding edge most of the time. Check 'em out. :-)
I'm sorry, but this simply doesn't apply here. The first rule of good UI design is to always go for the least surprising path. Emacs is anything but familiar for a first time user. Everything about it is different, including a huge number of things that don't need to be, like the basic shortcuts: copy/paste, save, search etc.
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.
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.
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.
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.
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.
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.
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 coughScalacough that have been around for a lot longer and really seem to be lagging behind in terms of tools.
Another possible 'canonical' solution is Technomancy (of leiningen fame)'s http://github.com/technomancy/emacs-starter-kit. Removed a lot of the futz of installing emacs for me. I still haven't worried about slime or swank yet, and i had to use elpa's installer to install a simple clojure-mode (M-x packages-install [enter] clojure-mode [enter] i think) but its got a basic solid seeming emacs with paredit and clojure stuff going for me.
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?
This does not include Clojure, nor Leningen (the Clojure build tool), nor does it work on Windows or any environment that does not have apt-get. No doubt, you will end up with a perfectly suitable environment for playing around with SBCL.
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.
How does one even know there is such a thing as SLIME or Clojure or Leningen? How does one even know that there are computers or that they can be programmed? How do you know?
I do not understand your point. If someone wants to learn Clojure, she certainly knows about Clojure. But she may not know (or care) about Leiningen, Emacs and the rest.
His point is that he doesn't know you need SBCL to program SBCL. At this point, the problem is not that it's too hard to install, it's that he's too dumb.
You have his point right. I just strongly disagree with it.
"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.
"A GUI is earier to deal with than an unresponsive terminal just Spanish is easier to learn than Chinese."
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.
The GP wasn't talking about complexities of Spanish and Chinese for native speakers, but for speakers of other similar languages.
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.
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:
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.
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.
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.
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.
From the "feed a man for life" department: http://www.emacswiki.org/ (That is, I recognize I am not pointing to specific issues, but this site is full of this sort of information. Sometimes hard to know if any given tidbit is up-to-date, emacs has been on the move lately.)
I linked to other posts in that post, in which you can see some of the things I struggled with (written while I was struggling). For example:
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.
> 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.
I've noticed a curious situation with learning (and configuring) emacs that once i've got it to be mostly[1] working i can remember all the little details that were causing me grief prior but cannot remember how I achieved the current workable state, and as a result I've never been able to pass on any of my own successes to another user.
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.
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!
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.
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.
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.
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.
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.
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?)
Clojure tool support is pretty rough, even when your main editor is Emacs. Not infrequently I have issues with swank/slime whereby I cannot load libraries correctly, maintain a proper connection or correctly eval a buffer (possibly related to the first issue mentioned). I hope that after 1.2 the community will stop changing the language, fix their infrastructure and let a set of libraries stabilize. Right now, half of the really nifty libraries are on 1.2, the other half on 1.1.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Vim? See http://vimdoc.sourceforge.net/htmldoc/if_ruby.html. (This, of course, depends on the level of integration you want. The above interface does require you to drop down to (generated) vimscript for many things.)
I started my career doing Perl CGI stuff, and have used, at various points, C, Python, Tcl, PHP, Erlang, Javascript and Ruby in addition to Java, Docbook, LaTeX, HTML (of course), CSS and various and sundry other things.
I think he's going in the other direction: All he knows is Ruby, yet he wants to extend his editor with additional functionality. (Which is less than useful IMO, because most of the time you don't really want to extend your editor in the sense of programming new things. My .emacs invariably has 40-50 lines, but none of them should be called programming).
I know many langauges, but I enjoy ruby the most. I'm not sure why programming an IDE and running arbitrary ruby programs wouldn't be useful?
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).
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.
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.
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.
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).
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.)
I don't know, I don't try to learn a new language every year. It seems like a lot of people who do make their way through Ruby, Python, Erlang, Clojure, Haskell, Scala; they all seem pretty dissimilar to me.
... but I suspect it to be largely true. I'd be hard pressed for finding a nicer, gui-ish-er editor that supports Haskell, C/C++ (with templates'n'stuff), Python/Cython, Java, Lisp/Scheme, shell and whatnot equally well.
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).
Exactly. It meant more: a customizable, scriptable editor that is more geared toward being adaptable to lots of things rather than (a) being extremely simple (e.g., pico, nano) or (b) being tailored towards one very specific thing (Eclipse, Netbeans).
(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 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.
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.
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.
Emacs is more than just slinging text. If you spend time in emacs you probably have it configured so that you rarely ever need to get out of emacs to get almost anything done. This doesn't happen over night though, your emacs config slowly evolves into something better than just a text editor.
Emacs is important in expressing myself. I use it more than any programming language, and also outside the context of programming. It's a rich computer in its own right, in many ways better than the underlying one.
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.
I'm not the standard user of emacs, but as an arts student in university, I have to write a lot of papers. I write, using LaTeX in emacs, and it has dramatically increased the speed in which I can write. More important is probably the editing portion of it. I don't have to worry about fooling around with font sizes and formatting, that if I make this bold it might make the rest, etc. all those little annoyances that come with a large word processor. I just want to write. Emacs lets me do that.
Of course, I'm not comparing emacs to vim, but to something like Word. I plan to learn vim in the next few months.
Indeed. Typing in the actual program text is both the least important task and the most important task. The program text is not what solves your problem, but without the program text, you don't have something you can actually run.
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.
Brian (the post's author) cited a year before he was proficient in emacs. I spent two months with it myself once, with nothing but frustration to show for it, so I can believe him on that front.
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. ;-))
Nobody wants to promote Emacs. The users are just so happy that they feel the need to share the experience.
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.
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.
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.)
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.
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.
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?
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.
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.
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. =)
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.