User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1)
            Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
References: <CANQYN6xiwms0LdCgW-6AQ9Pok9qbtc6k0ZgN40z6RK9+a=RdWg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4E9AF462.1010401@morningstar2.co.uk>
Date:         Sun, 16 Oct 2011 16:12:34 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Strings, and regular expressions
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <CANQYN6xiwms0LdCgW-6AQ9Pok9qbtc6k0ZgN40z6RK9+a=RdWg@mail.gmail.com>
Precedence: list
Status: R

On 10/10/2011 16:07, Bruno Le Floch wrote:
> The l3str module provides functions to get the length of a string,
> extract substrings or individual characters, testing for string
> equality (the curent \str_if_eq:nnTF). Some support for encodings is
> provided: percent encoding, conversion from utf-8 to a string of
> bytes, and most functions of Heiko Oberdiek's pdfescape package.
>hly welcome.

Some comments having read the code and documentation.

I don't like the name in \str_from_to:nnn - it sounds like a copy
function. What's wrong with \str_substr:nnn or just \str_sub:nnn?

In the same function, the indexing is described as "\meta{start index}
(inclusive) and \meta{end index} (exclusive)". This seems very odd to me
- I'd expect

  \str_from_to:nnn { abcdef } { 1 } { 4 }

to leave "bcde" in the input stream.

What's the reasoning for "\str_if_contains_char:NN" rather than just
"\str_if_in:NN"?

I see you have a number of "UTF_viii" functions. I can see that you are
covering any confusion with UTF-16, but would simply "UTF" be better?

I also saw that the docs mentioned "\str_if_UTF_viii:N", which does not
exist. I've removed it, as I think the docs and the code should match as
much as possible.
--
Joseph Wright