User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7)
            Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <4B727378.8060704@morningstar2.co.uk>,
            <4B729944.5050308@residenset.net>
            <OFD3BDE8BF.D25CA425-ON802576C6.0043FFAD-802576C6.0043FFAE@mcs-notes1.open.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <4B72B36E.6010401@morningstar2.co.uk>
Date:         Wed, 10 Feb 2010 13:23:58 +0000
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: String module
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <OFD3BDE8BF.D25CA425-ON802576C6.0043FFAD-802576C6.0043FFAE@mcs-notes1.open.ac.uk>
Precedence: list
Status: R

On 10/02/2010 12:22, Chris Rowley wrote:
> Apologies for the brevity.

Brevity is good if all the data are there :-)

> Also note that (as maybe someone already pointed out) in general a 'string of Unicode characters' is itself a rather slippery beast.  Thus when you 'put Unicode inside TeX' (whatever nmeaning you give that phrase) strings could be even more underspecified than Lars' list shows.

My take on this is that LaTeX3 should not do things like the current 
inputenc approach to utf8. There are perfectly good UTF-8 engines, and 
so I'm in favour of sticking to 8-bit input only with an 8-bit engine. 
So I would prefer it if each character was a character, with no danger 
of awkwardness.
-- 
Joseph Wright