Raúl,

Thank you for such a comprehensive response. :-)

> I have just one suggestion, but it is tightly coupled with my way of
> thinking about this kind of books ;) I think that the perfect place for
> tips and tricks is a wiki and not a book for one main reasons: the wiki
> allows readers to improve the tip/trick and update it when needed. It is
> more "alive" than a book, even if the book is online. For such a mutable
> thing as a tip'n'trick collection for a piece of software, keeping the
> book up to date is difficult, and in a wiki the effort is somewhat
> shared.

The Tips wiki is wonderful, but I think my approach has merit. The
wiki is a vast collection of often esoteric, terse tips. This is
useful for intermediate/expert users who already have a decent idea of
what they're looking for, but for new users it only furthers the
stereotype that Vim is obscure and difficult to use. In Vim Recipes I
have a far narrower focus, so can expand on solutions to common
problems, presenting them in an optimal fashion. Indeed, by
maintaining a common voice the book can suggest the best solution for
a given problem, rather than the grab-bag approach of the wiki. That
said, I could certainly do a far better job of pointing to relevant
pages on the Tips wiki from the recipes.

For example, the majority of "cheatsheets" and tip collections for Vim
suggest :wq as the way to save a file and quit. It was pointed out to
me, that :x actually makes more sense for most people. Unfortunately,
it's in this culture that questionable best practices are
disseminated. The goal is to publish large quantities of tips copied
from others rather than aiming for a sensible moderated collection
that is generally useful. Conversely, the official Vim documentation
is refreshingly thorough, as is befitting a reference work, but that
depth makes it unsuitable for quick study. Most users don't need to
know every way of solving every task, what the Vi equivalent is, and
how RISC OS implements a given function. ;-) My aim is to cherry pick
from the two poles.

In my experience, books released in wiki form are rarely significantly
expanded from their original remit, and the editor's primary role
becomes reverting spam edits. I have made the book's source available
in a Git repository, and indicated my willingness to accept
patches/suggestions, by e-mail. I also intend to add blog-like
comments to each recipe page. I feel that this is a reasonable
compromise, but if the consensus is that a wiki would make more sense,
I'll set it up.

Another benefit of my approach is that I'm able to produce the book in
different formats. I generate PDF and HTML at the moment, and would
like to expand this to ePub, at least. Long term I'd like to offer a
paperback version, as well, which again depends on consistent
formatting of the source.

I hope this goes some way to explaining why I'm being difficult. ;-)

-- 
Run Paint Run Run
<http://vim.runpaint.org/> / <http://twitter.com/runpaint>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply via email to