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.
|
