Loading ...
Sorry, an error occurred while loading the content.

130265Re: Vim manual

Expand Messages
  • Phil Dobbin
    Apr 10, 2012
      Hash: SHA1

      On 10/04/2012 18:12, shawn wilson wrote:

      > I think beautifying vimdoc would be a good thing (though I don't really
      > dig the dead tree version). I think maybe even expanding it so that it's
      > more book like (maybe with examples from the list / web) might even be a
      > good thing.
      > I think a starting point would be to decide on a document format (tex
      > probably?) and a conversion process so that the book is easily updated
      > with the upstream? ... and a git for this to live (someone's github
      > probably).
      > I worry about the process of design by committee though... if I have a
      > pull request where I use some font, who decides if its good or not?

      I have four github accounts so that's no problem. One is actually unused
      with a name that is non-specific to me. If it was to be made into a
      Vimdoc repo & named as such specific to say this list, it could be extra
      work handling pull requests although I think that that may be a good
      thing as that would help with the adding of examples & such if that idea
      was decided upon & better in general for the building of the book.

      I think the design by committee wouldn't be a problem. Input is good,
      natural & healthy & I think Bram should be the final arbiter after all.

      Putting the documents (manual & reference) into tex I think is the best
      way to go & will result in a much better looking final PDF from which to



      > On Apr 10, 2012 12:36 PM, "Phil Dobbin" <phildobbin@...
      > <mailto:phildobbin@...>> wrote:
      > On 10/04/2012 16:59, Andre Majorel wrote:
      >> On 2012-04-05 22:32 +0100, Phil Dobbin wrote:
      >>> There doesn't seem to have been much of a positive response
      > however to
      >>> the idea in general so taking that into account if the vim list is
      >>> ambivalent towards it, I'm not so sure it'll pan out with anyone
      > else.
      >>> It wouldn't take an Everest type effort to typeset it to a degree
      > (Lulu
      >>> accept pdf files) & it should, of course, look as well set as
      > possible.
      >> A straight conversion to PostScript of the help files would not
      >> be very difficult but it wouldn't be very good either.
      >> I've written a hack that darkens the colours and replaces the
      >> default font by something less rotten than courier (my beef is
      >> not with the fixed spacing, it is with that particular font).
      >> psbind -2 to print 2-up (4 pages per sheet).
      >> To do : a form-feed per chapter, global page numbering and
      >> everything else I'm forgetting. Maybe a page number after each
      >> link but that would mean reflowing.
      >> The manual is not very useful without the reference, IMO.
      > I've also been looking at Pandoc (been pretty busy of late so haven't
      > had much time).
      > I'm still very keen on the idea however so if you want maybe we can pool
      > resources (along with anybody else of course)?
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
      Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net
      Comment: GPGTools - http://gpgtools.org
      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

      -----END PGP SIGNATURE-----
    • Show all 19 messages in this topic