Hi,
the other thing is the "only two option bits remained" issue. Designing a new API is on the table for a long time, but we never actually started to do it. Personally I would do it first before add anything new feature to PCRE, and introducing pcre2.h.
Regards,
Zoltan
ph10@??? írta:
>On Thu, 23 May 2013, Giuseppe D'Angelo wrote:>
>
> No, because it hasn't to do with Unicode Properties -- it has to do>
> with setting up the case folding tables in a different way depending>
> on the user's language (if it's Turkish, "I" shouldn't fold to -->
> match caselessly -- "i").>
>
We can take our time discussing this, because it is now too late for any >
new changes to the forthcoming 8.33 release.>
>
The problem I see with local changes is the problem that Unicode is>
supposed to solve: what to do if a document is written in more than one>
language? If part is in English and part is in Turkish - which is quite>
possible in an English book that is discussing Turkish literature (or>
vice versa) - how can you have English rules for some parts and Turkish>
rules for others?>
>
PCRE currently gets its case-folding rules from the Unicode tables. I >
would be very loath to start introducing locale-specific exceptions - >
where does this end? I also see these problems:>
>
1. If the tables are modified at PCRE build time you get the best >
performance, but you are then restricted to one locale.>
>
2. If the tables are not modified, but special cases are detected at run >
time, performance is hit - for all users, not just those in the special >
locales.>
>
Perhaps whoever represents Turkish on the Unicode consortium should be >
lobbying for new characters I and i that do not fold to each other.>
>
Philip>
>
-- >
Philip Hazel>
>
-- >
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev >
