User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <4E934B91.4030205@latex-project.org>
Date:         Mon, 10 Oct 2011 21:46:25 +0200
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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
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

Hi Bruno,

a few comments on "random" parts of your message

> - Some day I may add printf-like string formatting. Is that useful?

I would think so. anything with input output formatting benefits from 
this. It is not a primary typesetting function but ... ;-)

> - Newlines. Currently, "." matches every character; in perl and PCRE
> it should not match new lines. As you know, the situation with new
> lines in TeX is a little bit odd, since they are converted to the
> \endlinechar upon reading, and normally not tokenized, simply giving
> rise to a space or a \par. Should we still decide that "." does not
> match the CR nor LF characters? Or should it simply no match the
> \endlinechar?

in my opinion we should accept that TeX strings do not have the notion 
of newlines thus one can't match against them

>
> - I had the idea of providing # as a shorthand for .*? (arbitrary
> sequence of characters, lazy), mimicking what TeX does when finding a
> macro parameter. Is it useful?

don't think this  requires adding an additional shorthand which is 
non-standard.

> - Same question for caseless matching, and for look-ahead/look-behind
> assertions.

personally (in other languages) I alway find it useful to be able to 
match  caseless (as an option). But then this requires an understanding 
on what is "case". Whether that is however important enough to go some 
length ... dunno

> Comments, feature requests, bug reports etc. are all highly welcome.
> Thanks for reading so far :).

I did ... read that far ;-)

cheers
frank