Hi Lars, Just a minor point or two. On 26/08/2009, at 8:21 AM, Lars Hellström wrote: > > One noticable difference to what I believe was discussed is in the > order of processors. If ">{A} o" means "grab optional argument, then > apply A", then I think it stands to reason that ">{B} >{A} o" should > mean "grab optional argument, then apply A, finally apply B", but as > implemented in revision 1494 it's B before A. (Reversing the > processing order would allow one to do without > \l_xparse_processor_use_int.) > > If you find it important that processors should be applied in left- > to-right order, then I believe they should appear after the argspec > base, perhaps as "o <{A} <{B}", to keep as invariant that the thing > being done first is closest to the argspec base. (SYNTAX CHANGE) > This may also have the added value of being more intuitive for users. I don't have strong opinions on the matter, but: (a) I prefer '>{A} m' over 'm <{A}' (b) I agree right-to-left makes some sense > \exp_args:NnV \@firstofone {#2} \l_xparse_arg_toks > % How do without \@firstofone here? The problem is that \exp_args are designed for expanding arguments being passed to a function, not for general expansion control; as you've noticed this means they have a tendency to surround everything with braces. I've proposed some extensions to \exp_after to allow this sort of thing (e.g., \exp_after:nV which would not brace-surround the first argument) but it hasn't been clear if it's useful enough, yet. (Also, instead of \@firstofone you can use \use:n if you wish) > In the typeset form, there is an index which should provide the same > functionality via hyperlinks (although for some reason all the links > seem to go to page 1; is that just for me or is it broken in l3doc > in general?) I've had similar problems in the past but they generally clear up with some magic number of LaTeX runs after the index generation. Or l3doc could be broken; it's not particularly nice code at the moment (my fault). > Some further introspection reveals that this happens inside an > expansion of \g_doc_functions_seq, which is very, VERY long. Hence I > suppose this "infinite loop" may in fact be an O(n^2) operation for > a very large n. Perhaps you should examine switching to a faster > algorithm, or provide some indication of progress? Indeed, what \g_doc_functions_seq is being used for is quite unnecessary for source3. This is disabled in the Makefile; I should probably turn it off by default in l3doc and only enable it when necessary. (It's checking that the functions documented with \begin{function} are also implemented with \begin{macro}, and warning of cases where functions have been implemented without documentation or vice versa.) In the meantime you should have more luck with `make sourcedoc`. Hope this helps, Will