ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Gerben Wierda <Gerben.Wierda@rna.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: cont-enp.pdf on lulu
Date: Mon, 28 Jul 2008 14:48:22 +0200	[thread overview]
Message-ID: <CB153721-6834-498F-BF4A-59FAB6AC0EAA@rna.nl> (raw)
In-Reply-To: <488DA374.8060404@elvenkind.com>

On Jul 28, 2008, at 12:46 PM, Taco Hoekwater wrote:

>
> Hi,
>
> While most of what Gerben states is close enough to the truth to
> be a matter of opinion, I really object to the tone of 'there is no
> documentation'. There is, in fact, a whole lot of documentation.
> It may be incomplete (especially when it comes to recent  
> developments),
> but that is quite different from not having documentation at all.
>
> There are thousands of pages of documentation on pragma-ade.com,
> and pretending they are totally inadequate by not even asserting
> their assistance is unfair.

OK Taco, that is a fair point concerning my pov. To answer it: I have  
made my comments knowing quite well what documentation there is and my  
*personal* (your mileage may vary) experience is that it hardly helps  
me. My personal experience has been with a result of close to 100%  
that if I want to do something / find out something I am unable to  
find it in the docs. Also, depending on what doc you take, I recall  
getting different solutions (I am reminded of the various incompatible  
ways to do tables) and if I recall correctly some of it had to be  
hunted down in MAPS articles and such. Maybe the answers of my  
questions are there. But in that case the documentation is such that I  
consider myself in the situation that I am unable to get my help from  
it.

And the documentation is not just incomplete for recent developments.

I have an idea. Why not have a live ConTeXt manual.pdf where you add  
something in the proper location and compile the document every time  
you answer a question from a user? As you are the person answering  
anyway, it should be little extra work.

For instance: I have put out a question about the (afaik completely  
undocumented, incomplete and certainly not recent) endnotes feature.  
Why not take the manual now, add the info in and recompile and do that  
every time a question arrives that is not in the manual or that is  
maybe unclear in the manual? I would suggest looking at ways to make  
it as easy as possible (that is, as little work as possible) for  
yourself to keep a user&reference manual up to date. Something simple  
and fundamental as endnotes should not be undocumented. And  
limitations (like what to do if you want images in endnotes) should be  
available in documentation.

In fact, you need only maintain one single integrated document en keep  
it up to date with the current ConTeXt version. Then, when you make  
MkIV the current ConTeXt version (and not a beta using a beta of a new  
compiler) you freeze the old and move to the new.

Is it perhaps the case that  the source of the manual is so old that  
it will not compile with a current ConTeXt anymore? If not, why not  
update it so it is less than 7 or 9 years out of date? If so, what  
does that possibly tell you about how valid the contents itself still  
are?

Yours,

G

PS. To my own surprise (as I am a TeX fan) I have recently started to  
think about researching non-TeX alternatives.

PPS. Before pressing send I just had a look at what is there on the  
pragma-ade site: http://www.pragma-ade.com/document-1.htm. I do not  
see any documentation other than the 1999 excursion and the 2001 'all  
of ConTeXt' manual. Maybe I am looking in the wrong place for  
documentation?
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


  reply	other threads:[~2008-07-28 12:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-21 23:58 abbg770
2008-07-22  0:37 ` John Culleton
2008-07-25 20:07   ` Gerben Wierda
2008-07-25 22:42     ` luigi scarso
2008-07-25 23:31     ` Aditya Mahajan
2008-07-26  2:38       ` Gerben Wierda
2008-07-27 19:40         ` David
2008-07-28  9:50           ` Gerben Wierda
2008-07-28 10:46             ` Taco Hoekwater
2008-07-28 12:48               ` Gerben Wierda [this message]
2008-07-28 12:57                 ` Taco Hoekwater
2008-07-28 14:11                   ` Aditya Mahajan
2008-07-28 23:07                 ` Uwe Koloska
2008-07-28 14:20           ` Hans Hagen
2008-07-28 15:44             ` Gerben Wierda
2008-07-28 20:36               ` Hans Hagen
2008-07-29  9:02                 ` Gerben Wierda
2008-07-29 12:44                   ` Aditya Mahajan
2008-07-29 20:01                     ` Gerben Wierda
2008-07-29 18:05                   ` Hans Hagen
2008-07-29 19:54                     ` Gerben Wierda
2008-07-30 16:21                     ` Fabrice Popineau
2008-07-31 16:17                       ` Hans Hagen

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=CB153721-6834-498F-BF4A-59FAB6AC0EAA@rna.nl \
    --to=gerben.wierda@rna.nl \
    --cc=ntg-context@ntg.nl \
    /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).