From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.tex.context/6539 Path: main.gmane.org!not-for-mail From: Hans Hagen Newsgroups: gmane.comp.tex.context Subject: Re: Modules Date: Sun, 20 Jan 2002 00:20:37 +0100 Sender: owner-ntg-context@let.uu.nl Message-ID: <5.1.0.14.1.20020119145525.0328d238@server-1> References: <20020117215748.GA762@localhost> <20020117215748.GA762@localhost> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Trace: main.gmane.org 1035397063 11504 80.91.224.250 (23 Oct 2002 18:17:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 18:17:43 +0000 (UTC) Cc: Marco Kuhlmann , ntg-context@ntg.nl Original-To: Giuseppe Bilotta In-Reply-To: <1078514762.20020118193025@bigfoot.com> Xref: main.gmane.org gmane.comp.tex.context:6539 X-Report-Spam: http://spam.gmane.org/gmane.comp.tex.context:6539 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/ 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 it maybe that texexec will control all of this Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl 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 -------------------------------------------------------------------------