git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, msysgit@googlegroups.com
Subject: Re: [msysGit] Re: WIP: asciidoc replacement
Date: Wed, 3 Oct 2007 12:50:01 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0710031239410.28395@racer.site> (raw)
In-Reply-To: <7vprzwhkgd.fsf@gitster.siamese.dyndns.org>

Hi,

On Tue, 2 Oct 2007, Junio C Hamano wrote:

> 
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > So here it is: a perl script that does a good job on many .txt files 
> > in Documentation/, although for some it deviates from "make man"'s 
> > output, and for others it is outright broken.  It is meant to be run 
> > in Documentation/.
> >
> > My intention is not to fix the script for all cases, but to make 
> > patches to Documentation/*.txt themselves, so that they are more 
> > consistent (and incidentally nicer to the script).
> 
> How you spend your time is up to you, but I need to wonder...
> 
>  - Is "man" format important for msysGit aka Windows
>    environment?  I had an impression that their helpfile format
>    were closer to "html" output.

I wanted something that can output both "man" and "html" output (and if 
some suck^Wlos^Wtexi-fan wants to provide it, also a "texi" or even "info" 
backend).

IMHO "man" needs a stricter framework in place, so I went with that.

>  - Does it make sense in the longer term for us to maintain
>    in-house documentation tools?  Can we afford it?

In the long run, I expect only few bugs (and I will try hard to squash 
them when they crop up, _and_ make this beast more maintainable whenever 
somebody has an idea how to do that).

However, it should definitely help keeping the docs clean, as now nobody 
has an excuse to test doc changes a la "I do not have asciidoc, so I do 
not know if it works, so please test".

> It appears that we heard about breakages for every minor docbook 
> updates, and it is really appealing if we do not have to rely on xsl 
> toolchain for manpage generation.

Exactly.

> But if patching the text means making it compatible with the in-house 
> script _and_ incompatible with AsciiDoc, hmmm...

No, I do not want it _incompatible_.  I want it _stricter_.  For example, 
you can do this in asciidoc:


    This is some paragraph that is indented,
    but the funny thing is:

This paragraph:
---------------

	is indented all the same!


So one thing I absolutely detest here is that you are free to use one, 
two, three or more spaces, or tabs, and asciidoc does the DWIMery of 
handling them the same.  But _not_ if there was any indentation before 
that with _less_ spaces and/or tabs!

Therefore I'd like to enforce strict rules here: Tab it is.  One tab per 
indentation level.  No spaces, no ambiguities.

Ciao,
Dscho

  parent reply	other threads:[~2007-10-03 11:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03  0:42 WIP: asciidoc replacement Johannes Schindelin
2007-10-03  1:56 ` Sam Vilain
2007-10-03  4:23   ` Johannes Schindelin
2007-10-03  4:51     ` Jeff King
2007-10-03 13:55     ` J. Bruce Fields
2007-10-04  4:13     ` Sam Vilain
2007-10-04 12:41       ` Johannes Schindelin
2007-10-03  6:40   ` Wincent Colaiuta
2007-10-03  4:48 ` Junio C Hamano
2007-10-03  6:34   ` Wincent Colaiuta
2007-10-03  8:12     ` David Kastrup
2007-10-03 10:05       ` Wincent Colaiuta
2007-10-03 10:25         ` David Kastrup
2007-10-03 10:52           ` Sam Ravnborg
2007-10-03 13:47           ` J. Bruce Fields
2007-10-03 14:01             ` David Kastrup
2007-10-03 10:57         ` Junio C Hamano
2007-10-03 17:46           ` Sam Ravnborg
2007-10-03 18:57             ` Johannes Schindelin
2007-10-03 19:21               ` Sam Ravnborg
2007-10-04  6:55           ` Martin Langhoff
2007-10-04 20:58             ` David Kastrup
2007-10-04 22:49               ` Martin Langhoff
2007-10-03 11:50   ` Johannes Schindelin [this message]
2007-10-03 12:02     ` [msysGit] " David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0710031239410.28395@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=msysgit@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).