I agree here. Regexps are by default not case sensitive, unless the i-modifier is set.
Isn't internal option setting an option? Like they do here: http://nl2.php.net/manual/en/regexp.reference.internal-options.php Example: (?i:foo) == Rene -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alejandro Guerrieri Sent: Monday, 30 August, 2010 16:31 To: Nikos Balkanas Cc: [email protected] Subject: Re: Patch: gw/urltrans.c Commenting inline. Regards, Alex On 30/08/2010, at 16:06, Nikos Balkanas wrote: > Hi, > > Please see comments inlined. > > Nikos > ----- Original Message ----- From: "Alexander Malysh" <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: <[email protected]> > Sent: Monday, August 30, 2010 12:08 PM > Subject: Re: Patch: gw/urltrans.c > > >>> Hi, > >>> why do you change explicit configuration to something implicit? > > I don't understand. Please explain what is explicit and what is implicit. > >>> user have to decide whether to use keyword or keyword-regex and if both >>> given >>> it's error and was indicated so. > > Just trying to align source with documentation, by popular demand. What's wrong with the actual functionality? You can't have both. > >>> About the case sensitivity, I would like to give a user possibility to >>> decide. >>> The policy should be: >>> - if keyword given make it case insensitive (just backwards compatibility) >>> - if keyword-regex given it's case sensitive > > That's confusing for anyone. How do you know what users want? It could blow > the list off. I think everything should be treated equally. keyword-regex is > just an extention of keyword. Rules applying to the first should apply to the > second as well. > > Any votes from the list? I concur with Alex. keyword-regex it's not an extension of keyword, but a different method for matching. If I have to pick an option, I'd stick with what we have now. HOWEVER, in an ideal world, we should be able to pass regexp switches. (e.g. in perl, you could do /foo/i and that means that matches "foo" without case sensitivity). If we'd devise a way to pass "i" and/or other switches on the keyword-regexp, it would definitely be the best of both worlds, since it would allow user control on case-sensitivity on a per-keyword-regexp basis. It could be an extra parameter "keyword-regexp-switches" (defaulting to none) or some funky syntax on the regexp itself. What do you think? > >>> So the patch should be: >>> - remove octstr_convert_range from find_translation >>> - add REG_ICASE for keyword >>> - documentation > > No problem, but first please address my points. > >>> Thanks, >>> Alexander Malysh > > Am 27.08.2010 um 02:24 schrieb Nikos Balkanas: > >> Added some needed initialization. Sorry about that. >> >> BR, >> Nikos >> ----- Original Message ----- From: "Nikos Balkanas" <[email protected]> >> To: <[email protected]> >> Cc: "Rene Kluwen" <[email protected]>; "'Alvaro Cornejo'" >> <[email protected]> >> Sent: Friday, August 27, 2010 1:30 AM >> Subject: Re: Patch: gw/urltrans.c >> >> >>> Case insensitivity is observed in the code. It just lacks in configuration. >>> I changed patch to match documentation: >>> >>> 1) When given both keyword-regex and keyword, it will just prefer >>> keyword-regex without complains (according to UG). >>> 2) It will accept any case in configuration for both keyword and >>> keyword-regex and do case incensitive matching. >>> 3) Fixed a diagnostic that was pooping up evrywhere during matches. >>> >>> Enjoy, >>> Nikos >>> ----- Original Message ----- From: "Rene Kluwen" <[email protected]> >>> To: "'Alvaro Cornejo'" <[email protected]>; "'Nikos Balkanas'" >>> <[email protected]> >>> Cc: <[email protected]> >>> Sent: Thursday, August 26, 2010 5:10 PM >>> Subject: RE: Patch: gw/urltrans.c >>> >>> >>> A lot of hand sets, nowadays automatically convert the first letter to >>> uppercase whilst typing an sms message. >>> >>> So I think case-insensivity is not a bad thing? >>> >>> == Rene >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of Alvaro Cornejo >>> Sent: Thursday, 26 August, 2010 15:44 >>> To: Nikos Balkanas >>> Cc: [email protected] >>> Subject: Re: Patch: gw/urltrans.c >>> >>> It should then be noted in the user guide. Otherwise we will continue >>> receiving this questions over and over. >>> >>> |--------------------------------------------------------------------------- >>> --------------------------------------| >>> Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier >>> celular y Nextel >>> en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 vias via >>> SMS y GPRS online >>> Visitenos en www.perusms.NET www.smsglobal.com.mx y >>> www.pravcom.com >>> >>> >>> >>> 2010/8/26 Nikos Balkanas <[email protected]>: >>>> I don't know if this is really necessary. Just using lower case in the >>>> keyword-regex pattern will work as well. Please disregard. >>>> >>>> BR, >>>> Nikos >>>> ----- Original Message ----- From: "Nikos Balkanas" <[email protected]> >>>> To: <[email protected]> >>>> Sent: Thursday, August 26, 2010 8:02 AM >>>> Subject: Patch: gw/urltrans.c >>>> >>>> >>>>> Hi, >>>>> >>>>> Currently keyword-regex is configured to only do exact case matches. This >>>>> is >>>>> in contrast to keyword matching, which is case incensitive. Additionaly, >>>>> input string input string is converted to lower case for matching. This >>>>> will >>>>> cause all keyword-regex patterns with capital letters to fail. >>>>> >>>>> This patch corrects that by inittializing keyword-regex to case >>>>> incensitive >>>>> matching. >>>>> Reported by Mike Cariotoglou >>>>> >>>>> BR, >>>>> Nikos >>>>> >>>> >>>> >>>> >>> >>> >> <urltrans.diff> > >
