Learn Emacs in Ten Years
edward.oconnor.cx
edward.oconnor.cx
But I have been using emacs for way more than ten years daily and still have much to learn.
Yes, I can imagine that you can learn vi in a shorter time, but I know very little about it. I actually know more about 'ed' than I do vi.
One (strenuous) exercise is to write a full, complete tutorial for a language. Explain it to your grandmother, for example. That will get you there quicker. And you will learn things about the product that you would not otherwise know.
Another exercise to completely learn a language is to write a compiler for it. This will flush out the corners of the language for you.
But these are admittedly a bit extreme methods.
I agree that it is worthwhile to master your tools.
Warning, there is a strong tendency to write a compiler for the language as you understand it, not as it is. The surface structure of the language, it's syntax, can be mastered by reading its grammar, and the kinks ironed out by actually implementing a lexer/parser for it.
However, it's deep structure, the semantics and evaluation are only understood through rigorous mathematical semantic models, or at least through implicit understanding after 10 years of use. At least for sophisticated languages.
A previous knowledge of other superior languages will corrupt your current attempt to understand an inferiour language. To give you an example, I think any Scheme programmer will have a difficult time implementing Pascal as it's specified. He will see the language lacking in drastic ways that can improved with little effort.
I think it would be a fun project to write a pascal compiler in scheme.
I argue that there are things that you are likely to run across in generating code that you might not see in mastering the language.
See, there are two kinds of study going on here. One is the study that I have done of emacs, which is what I think the article was talking about and that is starting with a small set of knowledge and expanding bit by bit as you use it in daily life.
The other kind of study, which I was trying to illustrate (and apparently failed) is a thorough, directed study (e. g., reading the User Manual and Report until it is about ready to fall apart), or reading the spec for the target language and working with the users closely. In the second case, we (three of us) wrote the compiler in a year, and just about replaced the use of assembler language in the OS project.
Even if you don't do any semantic modeling of the language itself, you most likely will be reading similar research done for a similar language.
You can teach yourself an Algol dialect by implementing it first (same thing with Forth) but that's pretty much about it. Even Griswold's Icon, procedural at it's, is more sophisticated than anything Algolish.
Now it would not be a fair test to go after scheme or lisp, as there are many examples out there of people who have implemented toy schemes and toy lisps. Toy here in the sense of tutorial or exploratory.
So being a simple country boy, I seem to be having trouble coming up with examples in line with your point. I wonder if you could give me some examples of non-procedural languages for which this exercise would not work--the exercise of writing a compiler for a language not being successful for learning the language without doing extensive rigorous mathematical semantic modeling?
Type theory would send anyone insane; static typing is trivial when you have a set of "primitive" types and another "derived" types; neither C nor Pascal nor another Algol dialect actually implement proper types. C gives you a bag of bytes in the form of a struct, and pointer to that back; you create your data structures with that. ML dialects take type theory to fantastic extremes. Throw pattern matching into the mix and your regular compiler hacker is off to reading the semantics literature.
Reasoning about lazy evaluation is also not trivial. It doesn't even show up in the mainstream compiler literature, which, by the way, has always been about creating the fastest Fortran dialect. Compiler research IS Fortran research, while the PL research is mostly FP research (even if it masquarades as OOP sometimes, usually for grant and resume purposes.)
Logical languages also are beyond the reach of someone coming from a classic compiler hacking background. LPLs are so far out that not even mainstream PL enthusiasts grok them.
All is not lost, however. At least one language, Forth, is trivial to implement, and best learned by implementing it first, as much as it's difficult to reason about. The problem with Forth is that there is nothing magical going on; it's a simple and beautiful little perversion, something that could only come out of a mind untainted by theory. Ditto with Perl, though by no means pretty. Perl has the finger prints of a hobbyist all over it.
You have already done BLISS, I have been meaning to clone it ever since I read an old rant by Dennis Ritchie on usenet. I am weirdly attracted to CMU languages, so I am gonna say Dylan :-) Marlais is open source and you can use it as a starting point. I am half way through cloning DUIM for Common Lisp and, frankly, all their "syntax" innovation would be lost to me. I am forever ruined for non-Lisp syntaxes, I think. ISO Lisp would be cool too.
If you weren't a compiler hacker I would have recommended Oberon.
For some reason, I could never see compiler hacking outside the traditional code generation for a real machine. If I wanna do source translation I would probably stick to macrology.
Miranda would be cool too, specially since there are no FLOSS compilers for it.
Mozart/Oz has a tiny kernel which you can clone, but I don't want you to learn this in that matter. Instead, get the book by van Roy and Haridi and enjoy at a leisurely pace.
Someday I would love to implement an APL and a Prolog dialect. Someday.
I really can't see where the fuss is. And I particularly agree with the following comment on the page:
"Wow, you spent ten years learning how to use emacs. In the same period of time you have earned a PhD, learned a few foreign languages, scaled a few mountains, learned several other computer languages like F#, Ruby, Scala, C# 4.0, started your own dot com, and gotten into great physical shape..."
I know I'm being pessimistic here, but it's not without reason. Back when I was a teenager I spend hours, weeks, months tweaking with linux kernels and the OS in general to make it run as smoothly as possible. Back then it was my passion, and I did learn a lot. But at the end of the road I realised that I could have done so much with my time because all that knowledge is now either lost or obsolete due to newer versions of linux software coming out fixing old bugs.
I went down the path of trying to master vi. This was more for the sake of looking "l33t" in the linux community than any job prospects/etc. It was painful and made me appreciate eclipse and other IDEs a lot more.
There seems to be a perception out there that being able to code an entire stand-alone application using vi or emacs is really awesome and cool. This inspires beginners to want to be just as cool and elite. And when they find out it's gonna take years they see it as even more of a challenge (and some sort of ego-boost), without actually thinking of the return on investment.
While really learning the nooks and crannies of Emacs's functionality can suck up a lot of time, it's also not going anywhere. I've only been using Emacs for about three years now, FWIW, but I'm a bit of a toolsmith, and I've learned enough to teach others. (FWIW, I'd also jump ship if a better editor comes around, but Emacs and Vim are each good enough that getting sufficient momentum with a new editor to displace them would be incredibly difficult. The most interesting alternative I've seen is Acme / Wily from Plan9, but I don't like its mouse-y interface.)
The best way to learn Emacs is to start with the tutorial (start Emacs, then press Control-h and then t), and then learn how to use the built-in help system. Everything is meticulously documented, though sometimes with unfamiliar terminology. It helps if you have a focus, like learning how to run make, a Python interpreter, etc. inside it. The Emacs Wiki (http://emacswiki.org) has quite a bit of good advice, as well.
Don't forget to keep your Emacs config under VC. :) Extension recommendations - pabbrev, tagging.el, uniquify, saveplace, recentf, remember, midnight, anything, and emacs-w3m if you're using Unix.
And org-mode rocks :-)
Marco Baringer's is the only good Emacs screencast I've seen so far. Please share if you find any other.
http://common-lisp.net/project/movies/movies/slime.mov [150MB]
I haven't gone through these yet, but you may want to check them out: http://www.emacswiki.org/emacs/EmacsScreencasts
Also, be sure to use this : http://steve.yegge.googlepages.com/effective-emacs
And he did it again that day, and made a bit more progress, and learned a beautiful proof for Weierstrass's theorem using the induced sheaf cohomology of the exponential sheaf sequence. Joe decided to use Windows XP -- he didn't want to think about all that lisp stuff today, and having nothing but Internet Explorer 6 (Joe only reads one page at a time) and Notepad to do his work with, he wrote the rest of his Latex notes in Notepad. And he felt happy, and went to bed -- which wasn't a bed, just a floor, as Joe was really a minimalist sort of guy.
==
How will Emacs enhance his experience (in any broad sense)? He doesn't compile often. Come to think of it, he probably doesn't need the preview-latex function either. In which forms do these gains come for him? Generally, what is the least complex form of editing that Emacs can still produce gains for?
C-s or C-r, type a few chars, <Enter>, continue editing
[1] since he is on Notepad at the moment
Any data formatting and parsing is extremely simple and easy, since this essentially becomes programming by doing. Much quicker than any other method I know and awesome for the many, many quick hacks one needs throughout the day.
There may be other people out there that use an editor, or an OS, to impress others; but from personal experience and those of friends, there are plenty of people that learn vi and Emacs because they needed to get things done.
The right tool for any job depends on the person. Someone familiar with the details of HTML and CSS would likely be better off not using a WYSIWYG editor, but for someone unaware of and uninterested in DOMs and stylesheets that editor would be great.
>Are there any websites/screencasts that show such "masters" in action?
Purely for the sake of motivation.
I can get things done with Textmate but I feel I've hit a wall in what I can do with it. I've used emacs off and on for about 6 months now and I really want to take it on full time.
What's dangerous is that the fiddling feels productive, even when you're just learning/making useless gimmicky features.
(defalias 'yes-or-no-p 'y-or-n-p) ;don't bug me
One thing about Emacs (mentioned in another comment in this thread) is that it is more than an editor but mostly used as an editor. It does not take 10 years to learn to use it as a better notepad (I mean, better pico... whatever), but mastering its existing (elisp) code base and adding to it (more than the trivial customization) takes a while indeed.
The article mentions some of the general reasons why it takes a while. Another one is that few people actually set out to "learn Emacs" as such, they just do it as an afterthought while working on other projects, and therefore not in a consistent and steady manner. So there may be months between "lessons" and, therefore, 10 years to complete a course, so to speak.
The part of Emacs that takes years to learn is integrating it with everything else. The core editor doesn't take long.
I have a hard time agreeing with this statement, especially since I experienced just that. The only thing I learned was that the documentation for the process was awful.
Furthermore, the statement is some curious attempt at irony that undermines his argument. I don't want to spend 10 years setting up a development environment, I want to spend 10 years learning a development environment. Such a line can be very fine, indeed.
(This being said as a regular Emacs user.)
Building a mail system into a single-threaded text editor seems a bit silly to me...
I have never encountered a system that could replace Gnus, though.
What do you use to read nntp, email and rss in a coherent interface?
I've never found an RSS reader I've been satisfied with, though. I was working on one at one point that had an interface like mh, but I haven't gotten back to it in a while.
Why's that? The (not gnus) mail system I use on Emacs will hang the Emacs process for a few seconds sometimes when I hit send while the Emacs process talks to my ISP's mail server, but that is the only way the mail system's single-threadedness ever really bites.
When I check for new mail on my ancient Pentium III system, the Emacs process hangs for less than a second or 2 usually.
Those delays are nothing compared to the time I waste waiting for Firefox to do something.
Plan9's ACME preserves most of what I like about Emacs, but it's mouse-chord-based UI is a dealbreaker for me.
Maybe it is because we were using Eclipse at my day job and I kept forgetting all the emacs commands, kept having the reflex to use the common key shortcuts for copy, paste undo etc. from the other applications I use. Maybe it was how slime would go crazy when doing scheme. Or maybe the fact that finding the keys for emacs sometimes proved problematic (when using cygwin outside of xwindows for example). Or the fact that aquamacs was slow to open on my mac, or that its default configuration was slow to open from the command line on my linux machine when I wanted to edit a line in a config file. How jumping around or scrolling a file was slow when you didn't know exactly what you were looking for. There were tons of small things that eventually added up and I always abandoned after a few weeks because I was losing productivity, was wasting time configuring or customizing it and the actual gains in productivity or features weren't that big compared to Eclipse, NetBeans, TextMate, XCode or other IDEs or editors.
Most of the comments raving about emacs (or at least the people I have met raving about emacs in real life) somehow seem to believe other editors are like notepad and lack search and other useful things. So I naïvely ask, is it really worth it?
[1] Or rather, "empowers you to do"
I'm a VIM user and I always like the cool things Emacs users can do, even though I'll never use Emacs.
Because emacs users and vim users are disjoint, despite having almost everything else in common!