an Emacs book - maybe
I've thought for a long time about writing an Emacs book. Since the recent release of Practical VIM I have thought more about it. The VIM book is very nice. And it's telling that a modern book about VIM (using the terminal is encouraged in this book!) is being sold. Many younger programmers are coming to VIM as a great text editing tool that makes you really quick and productive.
Emacs is experiencing something of an increase in popularity too. I believe this is directly correlated with a similar decrease in homogeneity in our industry. In short, the programming world is fracturing, many different languages are being picked up, new languages are being produced and Emacs and VIM are relatively quick ways to build tooling for new languages.
Languages that are less Emacs-able, like Java, seem to me to be seeing something of a decline.
If my theory is right then the upsurge won't last unless we Emacs advocates try and capitalize on it by trying hard to make good tools for the new languages and by documenting Emacs for the new generation of programmers.
reasons why people are considering Emacs
For one thing there's a whole generation of people who have never used Emacs and who aren't necessarily biased against it because of a poor experience. And Emacs has massively improved over the last 10 years, so a lot of the things that may have driven people away in the past have got better.
what's the right reason to use Emacs?
The right reason to use Emacs is that it's a tool for building editing tools.
VIM is a superior editor out of the box for nearly every conceivable editing task. But Emacs, with only a little customization, is soon just as good. And just as good specifically for you. And with a little more customization it's absolutely specifically your tool, crafted to your hands. Just like any master craftsmen the best programmers make their own tools. VIM users tend to make those tools out of the Unix shell. But in Emacs we think we have a better solution, a more flexible solution. Sometimes we can use the Unix way, sometimes we can use other methods.
The point about Emacs is it's hackability, the whole design of the system encourages people to make it better, for them.
This is also a fatal flaw for encouraging new people to use it. Especially people who aren't aware that programming is something of a craft.
It's also a fatal flaw for documenting Emacs. Much of the goodness of Emacs is add ons. One of the key things that makes Emacs great for Clojure users, paredit, doesn't even come with standard Emacs. And it's been superseded by a newer replacement, smartparens.
Whole chunks of Emacs clearly need replacing, dired is a particular abomination in my view. So anything that gets written may be woefully out of date in a few years.
How is anyone supposed to represent that dynamism in a positive way in a book?
It does seem someone should try and provide a decent medium level introduction to Emacs. People do expect such things to be around, they might even enjoy reading it. Certainly the VIM book is very good to dip into.
I like the idea of a tips book. It seems like the right thing for an editor.
So I think I will try and make this happen. I don't like writing particularly and the discipline of writing a book is very hard.
esr has persuaded
rms to switch Emacs to a modern
and popular source control system which should increase the
contributors and increase the rate of change. Also being considered is
a change of documentation system from texinfo to HTML.
Both these changes would be supported by a good tips book. Maybe we'd have to release it every 2 years to start with, or maybe it's just an online thing. I don't know. But I'm going to try.
Anyone who wants to help do get in touch via the usual channels.
update - 2014 September 24th
I've been looking into doing this but as I've done so a number of other, some what related efforts have started or come to my attention:
- @batsov's style guide
- endless parentheses is a blog, but a very good Emacs intro
- very much a programmer's intro book
I am still considering whether I should start work on something myself, start work on curating something or just contribute to one of the above.
Maybe you should too?