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! > > %<notpackage>\RequirePackage{l3io} > actually it works if there is a blank line after the \RequirePackage Indeed (I checked) - very interesting! > > \def_new:Npn\tools/xr/loop:n#1{\ior_open:Nn\@inputcheck{#1}\scan_stop: > > > > A gotcha: you now need the braces around #1. > > and no \scan_stop: :-) Yes, that's the sort of thing that happens when you don't think carefully about what you're doing. I plead that I was (and still am) suffering from a bad cold. > > The \\ in both these lines was \[log in to unmask] I wanted to change that to > > \tools/xr/dummy or something like that, but this doesn't work because > > \tools/xr/test:nnnn gets invoked when reading the .aux file, and at > > that stage / has catcode 12 again. (Using a _ wouldn't work either, > > of course.) > > ???? works i'd say in my implementation As usual you are right, and I can't even reproduce this problem. I think it happened when I was using the \RequirePackage, but it's not worth tracking down further at this stage. > ----------------- test > > \begin{filecontents}{l3xr} l3xr.sty, natch . . . > % well, that has already an interface in 2e > > \newcommand\externaldocument[2][] > { > { > \makeatletter > \def:Npn \l_xr_prefix_tlp {#1} > \seq_push:Nn \l_xr_subfiles_seq {#2.aux} > \xr_loop: > } > } > > \seq_new:N \l_xr_subfiles_seq 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: } } \tlp_new:Nn \l_xr_prefix_tlp {} \seq_new:N \l_xr_subfiles_seq > \def_new:Npn \xr_loop: > { > \seq_pop:NN \l_xr_subfiles_seq \l_xr_file_tlp > \ior_open:Nn \@inputcheck {\l_xr_file_tlp} > \ior_eof:NTF \@inputcheck > { > \PackageWarning{l3xr}{^^JNo~ file~ \l_xr_file_tlp^^JLABELS~ NOT~ IMPORTED.^^J} > } > { > \PackageInfo{l3xr}{IMPORTING~ LABELS~ FROM~ \l_xr_file_tlp} > \xr_read_file: > } > \seq_empty:NF \l_xr_subfiles_seq > { \xr_loop: } > } \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. And you to `declare' this as well: \tlp_new:N \l_xr_file_tlp {} The rest seems OK . . . . 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. 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!) > com'on. with a spec as is you can experiment with modules if you > really want to as easily as with some other. just introduce / as a > sub-module separator in the first word. you may be right that it would > look perhaps look ugly but it would work without any problem and would > prove either me or you wrong. > > 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. First impressions, using my example: \tools/xr/exp_list: becomes \tools/xr_exp_list: It has a certain `cringe factor' about it, because `xr' has somehow moved from the name of the package to the name of the function. To me, allowing _ within the <description> part and using it as the separator is really ugly. ObPolemic: But maybe the LaTeX world is too small for a hierarchical naming scheme - even though CTAN (not to mention TDS) would suggest otherwise.