On 23/08/2015 11:30 p.m., Joseph Wright wrote: > On 25/08/2015 01:33, aparsloe wrote: >> It has taken me a while to get to grips with \tl_set_rescan:Nnn <tl var> >> {setup} {tokens}, not least the fact that *omission* from the setup >> means "revert to usual catcode". I think this is worth documenting in >> interface3.pdf, since it seems not unreasonable (at least it did to me) >> to suppose that if one has explicitly changed a catcode using >> \tl_set_rescan:Nnn, only a similarly explicit change would revert the >> catcode to its usual value. In particular it would be helpful to >> document the fact that using an empty setup { } reverts everything to >> usual values. >> >> Andrew > I see what you mean: I'll add a note that any chars not set up > explicitly will have the *current* catcode applied. (That's not quite > the same as saying the 'usual' value.) > > Worth noting perhaps that rescanning tokens is in general a bit tricky > to use safely. (Certainly if possible I find other ways of solving > problems.) > -- > Joseph Wright (1) I wanted to use \tl_replace_all:Nnn on a token list that might contain braced groups. Using \tl_set_rescan:Nnn to change the category codes of { and } seemed the most direct way of proceeding. (Then resetting the category codes after replacement with an empty setup.) (2) Using \fp_to_scientific:n on the result of an l3fp calculation produces, say, 6.023e23. I want to write this as 6.023 \times 10^{23}, but the "e" of 6.023e23 doesn't have its "usual" catcode so \tl_replace_once:Nnn doesn't find the "e". (I presume "e" has catcode "other" -- I haven't checked.) Hence I rescan 6.023e23 with an empty setup and then use \tl_replace_once:Nnn (which now does find the "e"). Are there simple workarounds? Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus