At 07:30 PM 1/18/2002 +0100, Giuseppe Bilotta wrote:
>Thursday, January 17, 2002 Marco Kuhlmann wrote:
>
>MK> However, I wonder if not ConTeXt needs some of that LaTeX
>MK> feeling. In LaTeX, when you miss a feature, you know that there
>MK> is a package out there that implements it. In ConTeXt, you ask
>MK> Hans et al. Why are there so few modules?
>
>MK> It may of course be due to the relatively small number of
>MK> users.
>
>I think this is the main reason.
much of the functionality built in latex styles is available in the context
core so there is less need for modules
>MK> However, one important reason in my opinion is the lack
>MK> of a well-defined module interface. How should modules be
>MK> designed? Is there a standard library of functions that they
>MK> could or should use?
>
>I use pre-existent core and add-on modules to get the ideas for
>mine. Much of my knowledge of ConTeXt internal comes from studying
>the sources (of course, if Hans used English instead of Dutch, it
>would ease my work a lot ;-> but he's working along this path).
as long as you use a proper namespace in you local macros ...
also, you can use the *documented* low level macros in syst-*.tex and
supp-*.tex
>MK> If I wrote a new module, how would I
>MK> distribute it (for LaTeX, I would use CTAN)?
>
>I suppose you could put it on CTAN as well. Maybe CTAN should have
>a /third-party/<contributor name> set of directories under the
>context branch. And of course you could ask Hans to host it.
/third/...
with ... being something meaningful
also, the modules should have t-* names, no m-* or else
hosting is no problem,
>MK> What I propose it that we should think about going public.
>MK> ConTeXt has so much to offer, it should become more widely
>MK> used. A promising way to achieve this is to get more and more
>MK> people involved in enhancing and documenting it.
>
>How would you propose to do this? I've seen some new people
>posting about ConTeXt in the comp.text.tex newsgroup, but most
>ConTeXt question are put here (which sort of excludes us from the
>rest of the TeX community). Maybe Hans and the other experts could
>monitor those newsgroup, filtering out all messages which don't
>contain ConTeXt in the subject.
there is the everlasting mail list problem: beginners versus experienced users
now, with respect to comp.tex.whatever, i purposely am not on that list (i
don't want the overhead, don't want to be dragged into too many
discussions, etc). I leave it upto other members of the context list to
support those lists.
and ... filtering is not my strongest point
>Yet for ConTeXt to become widely used it would need to be at least
>on par with LaTeX, which it is currently not (e.g. I have to stick
>to LaTeX when doing heavy mathematics): when people would have to choose
>between ConTeXt and LaTeX they would go for the one which would
>present them less problems. ConTeXt has some very strong points,
>but they may not be the ones seeked by the users.
hm, i see no problem with using multiple packages along each other -)
you may expect more math in future versions
>MK> That does not
>MK> say, of course, that base ConTeXt could and should not remain
>MK> in the hands of PRAGMA. But an active community of developers
>MK> working on extensions to the core is a good thing. And if it is
>MK> well organised, it does not have to threaten the integrity of
>MK> the system as a whole.
>
>There are two things I don't like about the LaTeX packages:
>
>(1) their clashing with each other: this usually happens when two
>packages change the same LaTeX internal (LaTeX internals often
>don't offer hooks to the developers, which is pretty strange IMO
>considering how many LaTeX 'extenders' are there).
>
>We can prevent this in ConTeXt by requiring that no public module
>hacks any core command: if someone needs to extend a core command,
>he should ask Hans to provide a hook for the extensions.
right, normally i do my best to provide those hooks asap [and while
upgrading modules, i add more]
on my agenda is a reimplementation of some modules, after which the context
core should become relatively stable;
we could of course follow a ghostscript approach, with two versions etc etc
>(2) different packages achieving the same result in different
>ways: this is harder to deal with because the LaTeX situation
>comes from the fact that different people have different ideas on
>what should be achieved and why.
>
>We should then require that if an existing module with the same
>functionality is already provided, no new module should be
>implemented: if someone desires to change something, (s)he would
>provide a patch to the original module. Or something of the sort.
what i have in mind is a plug in model, as with the (rather beta) otr
modules, in that case (given a defined interface) users can pop in own
code, overload functionality etc. In that case there can be different
flavors as well as an official kernel
>Of course this would only hold for "public" modules.
>
>Another thing developers would need is a module interface to
>TeXUtil: when a ConTeXt module requires some particular
>postprocessing, it should provide a Perl module to be loaded by
>TeXUtil.
i know -) and hav esome ideas on that -) -)
>Extensions to TeXUtil should be "registered" so that the .tui file
>can contain hooks to modules in the form
>
>x <id> <data>
it maybe that texexec will control all of this
Hans
-------------------------------------------------------------------------
Hans Hagen | PRAGMA ADE | [EMAIL PROTECTED]
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
fall-back web server:
www.pragma-pod.nl
-------------------------------------------------------------------------
