From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/6527 Path: main.gmane.org!not-for-mail From: Giuseppe Bilotta Newsgroups: gmane.comp.tex.context Subject: Re: Modules Date: Fri, 18 Jan 2002 19:30:25 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <1078514762.20020118193025@bigfoot.com> References: <20020117215748.GA762@localhost> Reply-To: Giuseppe Bilotta NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1035397053 11418 80.91.224.250 (23 Oct 2002 18:17:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 18:17:33 +0000 (UTC) Cc: ntg-context@ntg.nl Original-To: Marco Kuhlmann In-Reply-To: <20020117215748.GA762@localhost> Xref: main.gmane.org gmane.comp.tex.context:6527 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:6527 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. 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). 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/ set of directories under the context branch. And of course you could ask Hans to host it. 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. 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. 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. (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. 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. Extensions to TeXUtil should be "registered" so that the .tui file can contain hooks to modules in the form x where x stands for extension and is a code registered by a module. TeXUtil would then call whatever appropriate routine is defined in the module hooking on extension and pass as the parameters. This is needed for example by a module of mine (x-desc), but could be needed by the bibliography module if we want to get rid of the bibtex executable (we could reimplement bibtex in Perl in a module called m-bib.pl so that when someone uses Taco's m-bib.tex module TeXUtil would also load the Perl bib module to deal with the bibliography data.) -- Giuseppe "Oblomov" Bilotta