Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index



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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.