On 25/08/2015 12:34, Bruno Le Floch wrote: > On 8/25/15, Joseph Wright <[log in to unmask]> wrote: >> On 26/08/2015 00:44, aparsloe wrote: >>> (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.) >> >> I see what you mean (I have a similar case in siunitx, for historical >> reasons). We'll explore what we can do with this: there are >> mapping-based approaches one can imagine that will enter brace groups. >> (We do that for \tl_lower_case:n, for example). However, for a general >> 'search and replace' I'd be slightly wary as the TeX convention that >> stuff in brace groups is 'special' is quite prevalent. (Depending on >> performance requirements, you might also look at l3regex if you are >> doing the replacement only very rarely.) >> >>> (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"). >> >> I see that we don't mention the catcode of "e" here: we should do >> (Bruno?). For this particular use case, I'd set up your search using a >> detokenized e >> >> \cs_generate_variant:Nn \tl_replace_all:Nnn { Nx } >> \tl_replace_all:Nnn <input> { \tl_to_str:n { e } } { \times } >> >> but probably with a dedicated function >> >> \cs_new:Npn \__mymodule_format:n #1 >> { \__mymodule_format:w #1 \q_stop } >> \use:x >> { >> \cs_new:Npn \exp_not:N \__mymodule_format:w >> ##1 \tl_to_str:n { e } ##2 \exp_not:N \q_stop >> } >> { \exp_not:n { #1 \times 10 ^ {##2} } } >> >> which can be made more 'robust' if you need to allow for cases where >> there is no "e". > > Actually, should we just make the "e" output by \fp_to_scientific:n > into a letter "e" rather than an other "e"? That's trivial to change, > and would be in line with how \int_to_roman:n produces letter > catcodes. I don't remember my rationale for outputting an other "e". > > Bruno I can see the logic in both :-) As this is *not* a 'string' function then I'd imagine normal (letter) catcode would be reasonable. Either way it should be documented. -- Joseph Wright