I like the idea of replacing the internal regexp in favor of a more fully developed regexp evaluator. The goal should be to get rid of the weaker regexp module. A question I don't know how to answer is which is the best replacement. As Thorsten points out, ideally the replacement should be enabled for localization and transliteration - again more stuff I don't understand well at all.
However, looking at textsearch.cxx in Open Grok -- http://opengrok.go-oo.org/xref/libs-gui/i18npool/source/search/textsearch.cxx#165 -- can see this comment before the various types of calls to a search routine: // use transliteration here, but only if not RegEx, which does it different One can also see other exclusion of the regexp search algorithm from the transliteration search prep and search result code in textsearch.cxx around the calls to the search routines, but I'm not absolutely sure that exclusion is complete. If the regexp search truly *never* uses transliteration then the swap out will be simpler and the change-over may actually enable transliteration. I haven't looked at the internal code of the regexp - perhaps it 'does it's own thing' internally for transliteration... -- View this message in context: http://nabble.documentfoundation.org/Crazy-Ideas-Discuss-Replace-regexp-parser-with-std-library-tp1974632p1989646.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
