Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Dec 2002 23:08:31 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id gBBM8STp024313 for ; Wed, 11 Dec 2002 23:08:29 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id gBBM1cxK018167; Wed, 11 Dec 2002 23:01:39 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2A161.D6F3D980" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id gBB2r51K030398; Wed, 11 Dec 2002 22:56:15 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 9940 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 11 Dec 2002 22:56:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id gBBLuFTk011361 for ; Wed, 11 Dec 2002 22:56:15 +0100 Received: from mercury.open.ac.uk (mercury.open.ac.uk [137.108.128.150]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id gBBM1XxK018134 for ; Wed, 11 Dec 2002 23:01:37 +0100 (MET) Received: from fell.open.ac.uk by mercury.open.ac.uk via SMTP Local (Mailer 3.1) with ESMTP; Wed, 11 Dec 2002 22:01:26 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.9.3+Sun/8.9.1) id WAA24359; Wed, 11 Dec 2002 22:01:23 GMT In-Reply-To: References: <20021210163647.73451db3.thomas.lotze@uni-jena.de> Return-Path: X-Mailer: VM 6.76 under Emacs 20.7.1 X-OriginalArrivalTime: 11 Dec 2002 22:08:31.0575 (UTC) FILETIME=[D74B9670:01C2A161] X-Authentication-Warning: fell.open.ac.uk: car2 set sender to car2@fell.open.ac.uk using -f X-Scanned-By: MIMEDefang 2.11 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Score: -1.2 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: Templates Date: Wed, 11 Dec 2002 23:01:22 +0100 Message-ID: A<15863.46514.997237.286071@fell.open.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Templates Thread-Index: AcKhYdh3v+L7ETrORMilvWEOw60zZg== From: "Chris Rowley" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4386 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2A161.D6F3D980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > > > >- In the template documentation, the question is raised whether a > > template type declaration should expect an argument containing a > > description of the semantics. I'm strongly in favour of this idea = and > > would even suggest that all declarations get a mandatory argument = for > > storing descriptive information, i.e. also those for templates and > > instances. (Together with another one for a one-line short = description > > this would make automatic documentation of designs possible and > > besides would encourage the programmer or designer to spell out = their > > ideas to themselves before coding.) > > I tend to disagree. There already is a standard (doc package / .dtx > sources) in the LaTeX world which is far more expressive than what one = can > achieve through mere command arguments, hence it would be = counterproductive > to try to force another level of (lower quality) documentation into = the > actual commands. > Not necessarily lower, just different, since this is part of a new LaTeX, which may have a programming environment associtaed with it one day; and this environment may be able to make use of some structured on-line brief info fields. This could be implemnted as above or as below. > A better idea would be to device a set of doc commands adapted to the = needs > of template documentation, and promote the use of those. More stuff to rmemeber? > A "smart editor" > should use the sources (.dtx) as reference for command definitions, = not the > "executables" (.sty and such). > These may also merge since it is not clear that much is saved these days by stripping the comments. chris ------_=_NextPart_001_01C2A161.D6F3D980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Templates

>
> >
> >- In the template documentation, the = question is raised whether a
> >  template type declaration should = expect an argument containing a
> >  description of the semantics. I'm = strongly in favour of this idea and
> >  would even suggest that all = declarations get a mandatory argument for
> >  storing descriptive information, i.e. = also those for templates and
> >  instances. (Together with another one = for a one-line short description
> >  this would make automatic = documentation of designs possible and
> >  besides would encourage the = programmer or designer to spell out their
> >  ideas to themselves before = coding.)
>
> I tend to disagree. There already is a standard = (doc package / .dtx
> sources) in the LaTeX world which is far more = expressive than what one can
> achieve through mere command arguments, hence it = would be counterproductive
> to try to force another level of (lower quality) = documentation into the
> actual commands.
>

Not necessarily lower, just different,
since this is part of a new LaTeX, which may have a = programming
environment associtaed with it one day; and this = environment may be
able to make use of some structured on-line brief = info fields.

This could be implemnted as above or as below.

> A better idea would be to device a set of doc = commands adapted to the needs
> of template documentation, and promote the use = of those.

More stuff to rmemeber?

> A "smart editor"
> should use the sources (.dtx) as reference for = command definitions, not the
> "executables" (.sty and such).
>

These may also merge since it is not clear that much = is saved these
days by stripping the comments.


chris

------_=_NextPart_001_01C2A161.D6F3D980--