LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Wed, 13 Aug 2014 18:53:24 +0200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=UTF-8
Bruno Le Floch <[log in to unmask]>
text/plain (51 lines)
On 8/13/14, Joseph Wright <[log in to unmask]> wrote:
> On 13/08/2014 10:42, aparsloe wrote:
>> I have been using l3regex and tripped on the following circumstance.
>> Suppose
>> \tl_set:Nn \l_tmpa_tl { abcdef }
>> Then
>> \regex_replace_all:nnN { cd } { 12 } \l_tmpa_tl
>> results in \l_tmpa_tl containing ab12ef, but there is no built-in
>> function for the analogous match or extract function. This was
>> disconcerting for a moment, to discover that I could replace text but
>> couldn't match it. Of course I can, but it means resorting to
>> \exp_args:Nno as in
>> \exp_args:Nno \regex_match:nnTF { cd } \l_tmpa_tl { true } { false }
>> It would be consistent with the presence of \regex_replace_all:nnN and
>> \regex_replace_all:NnN if there were corresponding functions,
>> \regex_match:nN and \regex_match:NN, and similarly for extract.
>> In the context in which I was working, the token list variable
>> (analogous to \l_tmpa_tl above) is set to a mathematical formula
>> elsewhere in the code. The formula is most naturally handled in this way
>> as a token list variable rather than as a token list.
>> Andrew
> There's a difference here between the two situations: in the replace
> case, you need to have an N-type argument as you've got to have a tl to
> set at the end of the process. On the other hand, in the case of
> matching it's unimportant if the tokens are given in a tl or are given
> explicitly. So
>     \cs_generate_variant:Nn \regex_match:nnTF { nV }
>     \regex_match:nVTF { cd } \l_tmpa_tl { true } { false }
> would be my preference here. (We don't claim to define all possible
> variants up-front, but there is nothing stopping you adding ones which
> are useful.)
> --
> Joseph Wright

I can confirm that Joseph's analysis of the situation.  l3regex
provides no variant defined through \cs_generate_variant:Nn, but they
can be defined in your own code.