Bug 144355 - [syntax highlighting] case insensitive WordRule
Summary: [syntax highlighting] case insensitive WordRule
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.2   Edit
Hardware: PC All
: P4 enhancement (vote)
Target Milestone: 3.3 M4   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks: 151172
  Show dependency tree
 
Reported: 2006-05-29 23:40 EDT by Alex Le CLA
Modified: 2006-11-21 09:03 EST (History)
3 users (show)

See Also:


Attachments
org.eclipse.jface.text.patch (7.91 KB, patch)
2006-11-16 16:51 EST, Chris Aniszczyk CLA
no flags Details | Diff
org.eclipse.jface.text.path (8.86 KB, patch)
2006-11-20 12:40 EST, Chris Aniszczyk CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Le CLA 2006-05-29 23:40:23 EDT
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.
Comment 1 Tom Hofmann CLA 2006-05-30 03:59:20 EDT
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.
Comment 2 Chris Aniszczyk CLA 2006-11-16 16:50:13 EST
seems reasonable
Comment 3 Chris Aniszczyk CLA 2006-11-16 16:51:06 EST
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 ;)
Comment 4 Chris Aniszczyk CLA 2006-11-16 16:51:30 EST
cc'ng Wassim as this is of interest to PDE
Comment 5 Alex Le CLA 2006-11-16 17:23:05 EST
(In reply to comment #4)
> cc'ng Wassim as this is of interest to PDE
> 

THANKS!
Comment 6 Wassim Melhem CLA 2006-11-16 18:54:17 EST
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.
Comment 7 Dani Megert CLA 2006-11-17 01:50:02 EST
Will look at this during M4.
Comment 8 Dani Megert CLA 2006-11-20 05:50:01 EST
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"
Comment 9 Chris Aniszczyk CLA 2006-11-20 12:40:04 EST
Created attachment 54182 [details]
org.eclipse.jface.text.path

Updated patch to comments mentioned and also made it adhere to Zurichian Notation :)
Comment 10 Dani Megert CLA 2006-11-21 09:03:52 EST
>- 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.