Community
Participate
Working Groups
Hi, The method WordRule.evaluate(ICharacterScanner scanner) needs to be flexible in checking if a word is in the map. The checking can be done with case insensitive or not. This way, the user does not have to specify "XYZ", "xyz", "Xyz", etc., as the same word. For example, we can add WordRule.setIgnoreCase(boolean). If this is set, then the statement "IToken token= (IToken) fWords.get(fBuffer.toString());" could be "IToken token= (IToken) fWords.get(fBuffer.toString().toUpperCase());" where the user has specified all the words in upper case.
A case insensitive word rule makes sense for certain languages (e.g. SQL). However, there are currently no plans to implement this. Feel free to provide a high quality patch including tests.
seems reasonable
Created attachment 54028 [details] org.eclipse.jface.text.patch Here is a stab at the desired functionality. Included is a unit test. Note my in depth knowledge of jface text isn't great ;)
cc'ng Wassim as this is of interest to PDE
(In reply to comment #4) > cc'ng Wassim as this is of interest to PDE > THANKS!
Hi Dani, This function is very important to the syntax highlighting of the MANIFEST.MF where the header names are case-insensitive. If the patch looks good to you, please release or ask our friend Chris to revise, if necessary. Thanks.
Will look at this during M4.
Hi Chris, the patch has two potential problems: 1) when setIgnoreCase is called after words have been added. I suggest to only allow to set this in the constructor. 2) the Georgian alphabet isn't treated right with this patch, see comments in String.regionMatches(...). If we assume that the word list is not too big then we could iterate over the entries and search for the first word that matches using equalsIgnoreCase(...) instead of using get(...). We would only do this if ignoreCase is true. Minor details: - call the existing constructor instead of copying its code - don't use 'this' qualification - use compact assignment, e.g. "foo= value" instead of "foo = value"
Created attachment 54182 [details] org.eclipse.jface.text.path Updated patch to comments mentioned and also made it adhere to Zurichian Notation :)
>- call the existing constructor instead of copying its code This has not been done. >Updated patch to comments mentioned and also made it adhere to Zurichian >Notation Almost - there are still some ugly non-compact assignments in the patch ;-) The loop continues even though the key has been found. This is bad for performance. I've fixed the above things and also a typo and a missing @since tag on the new field. Cmmitted the code to HEAD. Available in builds > I20061121-0800.