Hello Philip Hazel,
>> I think the chartables.c question is a political one: It depends on if
>> you put the PCRE focus on UTF-8 mode or not: Choose ASCII to point out
>> PCRE's non-UTF-8 mode, but go for ISO-8859-1 to stress PCRE's Unicode
>> capabilities and if you think that UTF-8 will become the de facto
>> Unicode Encoding of the future.
>
>I wouldn't presume to guess what will be the de facto encoding of the
>future! In any case, I am bad at predicting the future (see above re the
>src directory). Unicode itself does seem to be becoming fairly de facto
>(and that is an argument for making chartables 8859-1), but whether we
>will end up with UTF-8, UTF-16, or something else, or a mixture, who
>knows?
;-)
>Proposal:
>
>1. Distribute pcre_chartables.c with ISO-8859-1 values. This means
> that:
>
> . Anyone whose source contains only ASCII characters will be happy.
>
> . Anyone operating in non-UTF-8 mode, but with Unicode or 8859-1
> character values, will be happy.
>
> . Anybody operating in UTF-8 mode (assuming Unicode character values)
> will be happy.
Makes me 3 times happy!
>2. Add --rebuild-chartables to ./configure, and if possible, make it
> compile and run dftables at configure time in the current locale.
> This means that:
>
> . Anybody who relied on the previous behaviour in a non-8859-1 locale
> will be able to re-create it.
>
> . The few people (if any) who build PCRE in an EBCDIC environment can
> use this (we might even default it if EBCDIC is selected), so we
> don't have to distribute EBCDIC tables.
Thanks for summing this up so neatly!
Ralf
