Remembering what should go in the book
Writing a book about an open source editor and its extensions is
difficult. I want to describe many of the things people can do in
order to customize and make the most of Emacs, but I don’t want to
just rewrite the manual. I find myself summarizing a few bits and
expounding on others.
The key thing I want to add to this is excitement. I want people to be
able to *see* what these changes result in and how those changes will
improve their productivity or make them happier. ;) (Tall order for a
text editor!) I want this book to be less about a laundry list of
things people can do and more about looking over geeks’ shoulders and
being inspired to hack and learn more. That’s the kind of book I want
to write: a book that makes people go, “You can do that with Emacs?!”
I want to write a book that convinces people to spend some time
exploring the limits of their software (even vi!), because hidden
features can totally rock. I also want to write a book that shows how
all these little things combined can be absolutely cool, the way my
Planner+BBDB+Gnus+everything-else combination works out really well
for me. The whole is more than the sum of its parts.
I sometimes find it hard to hang on to that thought when I’m reading
the user’s manual and trying to make sure I’m covering the essentials.
I find myself writing from the point of view of the software instead
of from the point of view of the user. What I need to do is to focus
on the user’s story, on the problem or idea or opportunity. *Then* I
can write about solutions for that. I think I need to change the
outline I’m working with—it’s too software-centric.
It doesn’t have to be a perfect book, but I want it to be exciting and
alive. =)
Random Emacs symbol: tramp-uudecode – Variable: Shell function to implement `uudecode’ to standard output.
Short URL: http://sachachua.com/blog/p/4389![[me]](/blog/wp-content/themes/sacha-v3/images/face.png)
I'm 
