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