The search is case sensitive

[Anastasia Baryshnikova]

USE CASE: WHAT DO YOU WANT TO DO?

Find all matches for my search criteria.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

Type any search criteria into the search box.

CURRENT BEHAVIOR

1) While typing, the first letter is capitalized by default and the case of the other letters depends on how fast you type. If we wait a little between two letters and there's a match with what you typed so far, the second letter will have the same case as the partial match. If you type fast, you can insert whatever case you want.

2) The search is case sensitive. This is particularly a problem when all your labels are lower case: you start typing but the first letter is capitalized by default, so you cannot type the label properly. E.g., my labels start with "growth ...". I start typing "growth" but the first letter is capitalized by default, so I end up typing "Growth" and it doesn't find anything. The only way to find what you're looking for is to omit the first letter and search for rowth.

EXPECTED BEHAVIOR

The search should be case insensitive and should not change what you're typing.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

e.g. Add a color selection class

FILES AFFECTED (where the changes will be implemented) - developers only

e.g. selectColor.java & settingsPanel.java

LEVEL OF EFFORT - developers only

trivial/minor/medium/major/overhaul (choose one)

COMMENTS

[Christopher Keil]

@hepcat72, just a hint: If there is regex matching used for the search (I have no idea without looking at the newer code) then case insensitivity can simply be achieved by compiling the Pattern object with that option:

Pattern.compile("YOUR_REGEX", Pattern.CASE_INSENSITIVE);

[Robert Leach]

I do not believe that is the issue Chris. I am about to look into this, but what I believe is happening is that there is case in-sensistive matching and the first string to match in the combobox has a starting capital letter, which is replacing the lower case letter that was typed. Editing of this should be possible the way it currently exists, but as long as the first match has capital letters, it will always replace what was typed up until the lower-cased version differs with what has been typed thus far. I had gone to great lengths actually to make the text editable because I had been unable to enter what I'd wanted to enter awhile back. I will see though if I can reproduce the problem. The fix may actually be to make the search case sensitive and then if nothing matches, make it case-insensitive.

[Robert Leach]

@abarysh, could you include specific steps with an attached file (or a file referenced in the set of test files) used to reproduce this issue? It would look something like this:

1. Open myfile.cdt
2. Type this into the row search box: "growth factor 1"

[Anastasia Baryshnikova]

So, for example:

1. Load test_label_case.txt (I'll add it to the test ZIP file in a sec)
2. Find all rows that start with "a": try typing in the row search box: "a*" -- doesn't work, "a" is automatically transformed into "A"

[Robert Leach]

I was able to partially reproduce this issue and I can definitely fix it to return case-insensitive matches, but I think there's another issue due to some sort of slowness of the specific computer being used during the moment a search was being performed. Here's what I've found.

The first letters (plural) are indeed capitalized... but only if the first case-insensitive matched label is capitalized, because what was typed is autofilled by the matching label, which happens to start with capital letters (e.g. the "g" gets capitalized because it matches "GENE..." before it matches "growth"). The user can continue to type their search and as soon as the two labels differ, the case will switch to the next matching label. For example, my data has these labels (among others):

RAVE complex Rad53p/Asf1p complex

When I type "rad", the "r" and the "a", as I type them, are replaced with "R" and "A", along with the rest of the highlighted "VE complex" string. As soon as I type "d", the whole string is replaced with "Rad53p/Asf1p complex", where 5... is the highlighted autofill.

I believe this to be common/expected/desired behavior and is pretty close to google's autofill behavior. The difference being that google's autofill is smart enough to not change the case of what you've already typed, but the end result is the same.

When I use the search box, the autofill is instantaneous, so I find it concerning that you describe being able to type faster than the search box can perform its autofill operation. Was your computer slow overall at the time? How big is your file and how many label types do you have? So I suspect that maybe you're simply entering "growth" and hitting enter faster than your computer was able to perform the autofill because it should be autofilling, as that's what it does when I try it. In fact, I cannot reproduce your issue as you describe it because the case always changes to something that is a case-insensitive-match if it exists in the labels. I.e. I cannot perform a search using the string "Growth" because it is autofilled with "growth...".

Regardless, "Growth" still should have matched, and I was able to confirm that it does not by using the equivalent of the search "Growth" and got no results, whereas "growth does match.

So I think that if I simply address that case-sensitivity of the search after the autofill, this whole issue will be resolved.

There are a couple other issues I encounter however, when I tried every letter of the alphabet.

1. When I got to "s", it autofilled "Search Rows...", which I think is confusing, especially since all the rest of the matching "s" strings are not immediately visible in the drop-down. This could be improved by somehow preventing that string to be matched.
2. Hitting the command key in an attempt to open a file using "command-o", causes the search box's dropdown to reveal itself, which is confusing. I think that should be remedied.
3. The label sort in the search box's drop-down sorts all capital letters before lower case letters. For example: RAV..., RES..., RIM..., RNA..., RTG..., Rad... I believe it would be better if the sort was case-insensitive, so that the series above would start with Rad...

[Robert Leach]

Great, I will test the file you upload and the case you described.

[Anastasia Baryshnikova]

Yeah, I agree that addressing the case-sensitivity issue should get the whole thing resolved.

[Robert Leach]

OK, I have fixed the case sensitivity. @TreeView3Dev - you were in fact correct. I did use your regex compile method.

[Robert Leach]

I tried the test case. True "a" is replaced by a capital "A". True "A*" is case sensitive. However, one is able to highlight the "A" in "A*" and type a lower-case "a" resulting in the string "a*" which gets the desired result. This case sensitivity is fixed in my current working branch. I think that I can also force the entered text to retain its entered capitalization without much effort.

[Anastasia Baryshnikova]

Yeah, ideally the entered capitalization would be preserved. I think it would give users confidence that we're not manipulating their search.

[Robert Leach]

Well, I found out that I cannot preserve the case of the string. If it matches something in the drop-down, any case edits I do get changed to the string of the matching dropdown item regardless.

These changes are ready for a pull request. Submitting momentarily.

[Robert Leach]

Fixed in branch issue348...

[Robert Leach]

Merged to master.

[Robert Leach]

Removing milestone: Search (automated comment)