Richard Walker writes: > Frank Mittelbach writes: > > fine, however you could take the exercise further and actually apply > > some of the functionality of L3PL. i've appended my version below > > Yes, I could have done that if I knew what I was doing! no critique intended. i know that this is not easy if you haven't felt yourself around in those set of functions. > > > %<notpackage>\RequirePackage{l3io} > > actually it works if there is a blank line after the \RequirePackage > > Indeed (I checked) - very interesting! not really, just a bloody pain in the neck which should get fixed at some point even though the current mix of 2e + L3PL is only for experiments anyway > > ----------------- test > > > > \begin{filecontents}{l3xr} > > l3xr.sty, natch . . . guilty. comes from doing manual changes in the code without rechecking it. should know not to do this. > No, if you want to do it `properly' you must say: > > \newcommand\externaldocument[2][] > { > { > \makeatletter > \tlp_set:Nn \l_xr_prefix_tlp {#1} > \seq_push:Nn \l_xr_subfiles_seq {#2.aux} > \xr_loop: > } > } again caught :-( in fact i saw that one the moment the mail went out i can't claim any cold though the whether is good for getting one. my only excuse is that mainly i was doing what you (probably) did, namely search and replace first with some cosmetic fixes. > \seq_pop:NN is not listed in the first part of the l3seq > documentation. It was not obvious that one is allowed/supposed to use > it. is it not? oversight, then probably the whole set of stack type of commands is missing. it is indeed. sorry for that. will see that this gets updated soon. but essentially all the stuff in the implementation section about stacks is intended for general use. > The rest seems OK . . . . what a relieve :-) > Tim's questions are really quite important for the `average' package > writer, because they will be programing `in-the-small', and the xr > example is quite a good one for that. Even such a small package has > needed a total re-think and re-writing. true but is it so much different from having to hunt through the LaTeX source to find you way in providing packages? After all a lot of the documentation therein was provided by us during the last years before that its internal documentation was very much out of date (still is in some parts). what i mean is, you need to have got a feeling for it but that it true right now as well except that right now because of nearly no conventions people are forced to reinvent the wheel over and over just because they don't know that some command or datatype or whatever already exist somewhere. so yes you need a re-think, you probably don't need much of a rewriting for an existing package if you just mainly do a manual translation but you can gain a lot once you start replacing all you low-level private code by already provided solutions for many of the basic functionality which right now is often repeated over and over again in packages. > Clearly I haven't yet got my brain around what one is supposed to do > with all of the new data types (prop, seq, tlp) - and I doubt anyone > else listening has. Because there are no examples I have to do a lot > of mind-reading. So I am going to study your l3xr more carefully and > have a go at a larger package. (I've been in Melbourne since February > and I'm moving back to Canberra this week, so don't hold your breath - > but I'll do my best!) i hope that we can provide more examples and others do so as well. > > so \foo_bar:nn would be module foo function bar > > and \foo/baz_bar:nn would be module foo submodule baz function bar > > > > so what? (and it doesn't look so bad actually) > > I am going to think about that one for a while. it is not perfect. all i was trying to say is that even within the current spec you could implement a module/submodule and thus experiment with it. my whole point is that for this the current spec doesn't need changing right now! frank