Comment 1 Martin Aeschlimann 2005-09-17 08:30:36 EDT

Makes sense to me. Dirk?

Comment 2 Dirk Baeumer 2005-09-19 09:31:00 EDT

Agree

Comment 3 Dirk Baeumer 2005-10-31 06:38:36 EST

Moving to Core. We are now reusing camel case matching routines defined in Core.

Comment 4 Philipe Mulet 2005-10-31 08:16:28 EST

Need to think about it. In this case, it probably makes sense, but what about
middle digit characters (if any). Unclear whether digits are significant in
general in names. 

UTF16DocumentScannerSupport will be painful to reach if we do this.

Comment 5 Frederic Fusier 2005-11-18 11:49:55 EST

*** Bug 99195 has been marked as a duplicate of this bug. ***

Comment 6 Pratik Shah 2005-11-18 13:13:55 EST

Perhaps, results with numbers can be hit both with or without numbers?  So, 
UTF16DSS and UTFDSS would both find UTF16DocumentScannerSupport.

Comment 7 David Audel 2005-12-08 06:34:01 EST

*** Bug 119842 has been marked as a duplicate of this bug. ***

Comment 8 Dirk Baeumer 2005-12-16 04:06:22 EST

*** Bug 121130 has been marked as a duplicate of this bug. ***

Comment 9 Dani Megert 2006-02-03 07:30:33 EST

It's also not possible to use a '*', e.g. when trying to enter IDocumentExtension3 "IDE*3" doesn't work.

Comment 10 Frederic Fusier 2006-04-26 11:50:40 EDT

Too late to work on this enhancement => defer to 3.3

Comment 11 Dani Megert 2006-06-12 10:34:47 EDT

Can this now be reopened?

Comment 12 Frederic Fusier 2006-06-12 10:41:14 EDT

Of course...

Comment 13 Markus Keller 2007-01-18 06:40:02 EST

*** Bug 170842 has been marked as a duplicate of this bug. ***

Comment 14 Frederic Fusier 2007-05-11 05:29:55 EDT

Unfortunately, I have to defer this again to next release...

Comment 15 Markus Keller 2007-05-11 13:20:02 EDT

Also see bug 176017. Every change to JDT/Core's SearchPattern potentially breaks the Open Type dialog (same for changes in Platfom/UI's SearchPattern).

Comment 16 Markus Keller 2007-07-18 12:50:15 EDT

*** Bug 196804 has been marked as a duplicate of this bug. ***

Comment 17 Frederic Fusier 2007-08-09 08:52:06 EDT

Created attachment 75758 [details]
Proposed patch

Comment 18 Frederic Fusier 2007-08-09 09:58:59 EDT

Created attachment 75766 [details]
Corresponding patch for org.eclipse.ui.workbench

Here's a patch to apply on org.eclipse.ui.workbench project (version I20070802-0800) to have corresponding changes in org.eclipse.ui.dialogs.SearchPattern.

I agree with Markus that bug 176017 definitely and urgently needs to be fixed as this is really a pain to maintain both versions of code.

Note that I already simplified JDT/Core code by removing code duplicates between SearchPattern and CharOperation (see my previous patch to apply on org.eclipse.jdt.core project...)

Comment 19 Frederic Fusier 2007-08-09 11:38:58 EDT

Markus,

All JDT/Core + JDT/UI tests pass with this patch. Please let me know if this OK for you that I release the JDT/Core patch or if you think it could break something in Open Type dialog...

Thanks

Comment 20 Markus Keller 2007-08-09 13:08:18 EDT

I'll take care of bug 176017 asap. I would prefer if you could keep this fix back until bug 176017 is resolved. We don't have many automated tests in that area, so I can't tell whether it would break the Open Type dialog without extensive testing -- which I won't do now just to do it again after I've fixed bug 176017.

But if you've tested the Open Type dialog a bit and love to take risks, you can also release it...

Comment 21 Frederic Fusier 2007-08-09 15:18:16 EDT

I do prefer not to take any risk! So, I'll wait until bug 176017 is fixed...

Comment 22 Frederic Fusier 2007-08-16 09:12:36 EDT

Released for 3.4M2 in HEAD.

Comment 23 Markus Keller 2007-08-16 13:37:16 EDT

The fix in HEAD does not seem to work properly.

With these classes:

class MyClass1 {}
class MyClass123 {}
class MyClass123Extension {}
class MyClass123Extension1 {}

... neither MC1 nor MyCla1 matched anything.

Comment 24 Frederic Fusier 2007-08-16 16:05:31 EDT

I missed the fact that matchRule was verified using validateMatchRule(String, int) of SearchPattern. A digit is now a valid char (when not the first) for camel case patterns...

Comment 25 Frederic Fusier 2007-08-16 16:11:15 EDT

Created attachment 76257 [details]
Additional patch

Comment 26 Frederic Fusier 2007-08-17 02:26:17 EDT

Additional patch released in HEAD.

Comment 27 Markus Keller 2007-08-17 08:56:13 EDT

In HEAD, MC2 and MC13 both match all the MyClass123* classes from comment 23. I would have expected that these patterns don't match.

IMO, the first digit of each multi-digit number should be considered as uppercase letter, and the other digits as lowercase letters.

Comment 28 Frederic Fusier 2007-08-17 09:20:36 EDT

(In reply to comment #27)
> IMO, the first digit of each multi-digit number should be considered as
> uppercase letter, and the other digits as lowercase letters.
> 
This is more restrictive and I'm afraid some other users will complain that you need to know the numbers order while hitting the pattern to get the correct matches... Several digits in sequence are seldom used in Java identifiers, so I would prefer let the current implementation more permissive and see if we got complains about it.

The hidden reason for waiting is that more restrictive implementation will request a more complex and slower algorithm. All users will then be penalized and I do not want to go this way unless a strong need is identified.

Comment 29 Pratik Shah 2007-08-19 12:05:53 EDT

(In reply to comment #27)
> In HEAD, MC2 and MC13 both match all the MyClass123* classes from comment 23. I
> would have expected that these patterns don't match.

I would've expected the same, although I don't think the answer is to treat only the first digit of each multi-digit number as upper-case.  I think each number should be treated as upper-case.  The class ABCD can't be found with "ABD", and it should be the same way with numbers.

I know this contradicts what I said in comment 6.

Comment 30 Frederic Fusier 2007-08-20 11:43:49 EDT

(In reply to comment #29)
> I would've expected the same, although I don't think the answer is to treat
> only the first digit of each multi-digit number as upper-case.  I think each
> number should be treated as upper-case.  The class ABCD can't be found with
> "ABD", and it should be the same way with numbers.
> 
> I know this contradicts what I said in comment 6.
> 
My opinion is that without real specification, the safer implementation is allow both cases. That's why digits are considered as uppercase character but are also tolerated as lowercase characters in the algorithm.

I do not think one implementation may satisfy all users (since I released this fix, 2 remarks = 2 different ways to treat digits in the patterns...). So, I'd strongly prefer in this case to be more permissive and return too much matches than not enough.

However, if the number of valid matches would be really too large, then I'd agree to make the algorithm more restrictive. But it seems that this test case hasn't been experimented by any user yet...

Comment 31 Eric Jodet 2007-09-17 10:39:34 EDT

Verified for 3.4 M2 using build I20070917-0010.

Comment 32 Adam Hawthorne 2012-12-10 09:48:55 EST

I was about to open a new bug because this behavior is not working (to my knowledge, I have never seen it work).  I have a class 'CommTablesFactory2'.  I type 'CTF2' in the "Open Resource" window, and it does not appear.  Should I open a new bug, or should this bug be reopened?

Comment 33 Dani Megert 2012-12-10 09:56:30 EST

(In reply to comment #32)
> I was about to open a new bug because this behavior is not working (to my
> knowledge, I have never seen it work).  I have a class 'CommTablesFactory2'.
> I type 'CTF2' in the "Open Resource" window, and it does not appear.  Should
> I open a new bug, or should this bug be reopened?

This bug here is for Java (Open Type) and *is* fixed. Please file a new bug against Platform IDE (Open Resource).

Comment 34 Adam Hawthorne 2012-12-10 10:08:50 EST

Sorry, it wasn't clear from the bug that it referred only to the Open Type dialog.  I'll open a new bug.