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