Community
Participate
Working Groups
Let me reuse the screenshot from bug 376674 > Created attachment 214340 [details] In my opinion everything below 'newTypeParameter' is noise and a user does not want those proposals when 'para*' is typed. Note the * at the end of 'para*', I am saying that the user can type more characters but would still not want any of the proposals coming towards the end. I am assuming that when a human invokes content assist he has either typed - a word or a sequence of words e.g. newtype (new+type) - first letter(s) of a sequence of words e.g. ntp or newtp (new+Type+Parameter) Would someone do it any other way? With the above assumptions in mind I think the following proposals make no sense - newTypeDeclaration ^ ^^^ - newPackageDeclaration ^^ ^^ Now camel case convention in java names provides clear word boundaries. I think we should discard any proposal where a sequence of matched characters does NOT begin at a word. Does this sound reasonable?
I think treating matches on word boundaries in a special way is reasonable - although I'm not fully convinced that it's always/often unwanted noise. But most of the time we might use 'real' subwords as tokens. However, I'd like to go one step further. You might use something like 'mgr' to find proposal that contain the word 'manager' or 'hw' for 'hardware'. We often use abbreviations or even tokens that do not syntactically match. Does this work well with your approach? I stille like the idea how the "Abbreviation Completion" works. Although this may be a bit too radical... ;) I think, we need some empirical data that supports our claims. We actually have given away a hands-on writing a 'proposal logger' (it logs which proposals are actually selected with which prefix etc. and where and stores this data on some server). I think this could help us much to gather the required information to support your (and maybe my) claims. What do you think?
(In reply to comment #1) > I think treating matches on word boundaries in a special way is reasonable - > although I'm not fully convinced that it's always/often unwanted noise. But > most of the time we might use 'real' subwords as tokens. > > However, I'd like to go one step further. You might use something like 'mgr' to > find proposal that contain the word 'manager' or 'hw' for 'hardware'. We often > use abbreviations or even tokens that do not syntactically match. Point taken. > Does this work well with your approach? I think it could. Let's say there is a method 'getHardwareManager()' and let's see what all should match this - mgr getHardwareManager ^ ^ ^ => first letter of the word is included in the match - OK - hw getHardwareManager ^ ^ => first letter of the word is included in the match - OK - age getHardwareManager ^^^ => first letter of a word is NOT included in the match - Discard Essentially, if some characters in a word are matched but not the first one we should discard the proposal. Even with this rule all the unwanted proposals from screenshot in comment 0 are discarded.
(In reply to comment #2) > Essentially, if some characters in a word are matched but not the first one we > should discard the proposal. Even with this rule all the unwanted proposals > from screenshot in comment 0 are discarded. Seems worth trying. The simplest heuristic(!) that comes close to what you want, is to add a filter that checks that at least one upper case letter is in the match. This is would be a fast and experimental (!) hack to see how this filtering works out in practice. If this is actually what we want, we can think about developing a clean approach. If you have more of these ideas, you may consider writing patches ;)
(In reply to comment #3) > If you have more of these ideas, you may consider writing patches ;) Yes, I already considered that option :-) I will keep opening bugs, and if they do not get fixed I will try to take a look at them myself. But I do not see that happening at least for the next month or so.
(In reply to comment #4) > (In reply to comment #3) > > If you have more of these ideas, you may consider writing patches ;) > Yes, I already considered that option :-) Great! > I will keep opening bugs, and if they do not get fixed I will try to take a > look at them myself. But I do not see that happening at least for the next > month or so. Sounds good. I've to focus on the other tools for Juno too. So the time I can spent on subwords will be limited. My goal is to make it a useful addition for Juno but not feature-complete, i.e., fix every severe issue but postpone some ideas after Juno. If you or someone else provides patches, however, I'd be glad to integrate them. But for know: Just keep ideas coming ;)
Created attachment 214345 [details] Now it feels like 'camel case matching ++' Is this the intended goal? A better (read, more permissive) camel case matching? Is there a 'real' delta to camel case matching except that you can write more letters and can start with fragments of the camel case (as depicted in the screenshot)?
(In reply to comment #6) > Created attachment 214345 [details] > Now it feels like 'camel case matching ++' > > Is this the intended goal? A better (read, more permissive) camel case > matching? Is there a 'real' delta to camel case matching except that you can > write more letters and can start with fragments of the camel case (as depicted > in the screenshot)? There is a real delta with respect to camel case (in addition to what you already mentioned) - You do not have to type in upper case - You do not have to type first letters of all the words Calling it 'camel case matching ++' may not be best. It is really Subword completion which accounts for words in a java name.
you planned that long beforehand, right ? ;) I'm fine with the current implementation. Let's give it a try and see how people like it.
(In reply to comment #8) > I'm fine with the current > implementation. Let's give it a try and see how people like it. Ok, let me know when you release this.
http://download.eclipse.org/recommenders/updates/head/e42 now contains the binaries.
Looks good so far! (In reply to comment #3) > Seems worth trying. The simplest heuristic(!) that comes close to what you > want, is to add a filter that checks that at least one upper case letter is in > the match. > > This is would be a fast and experimental (!) hack to see how this filtering > works out in practice. If this is actually what we want, we can think about > developing a clean approach. Just to confirm, you implemented the full solution, right?
(In reply to comment #11) > Just to confirm, you implemented the full solution, right? There are one or two cases that may be unexpected and I'm just relying on a very small test suite at the moment. But yes, it's more than the heuristic mentioned above.
Set target milestone for fixed bugs to 1.0
Juno shipped, change was made. Closing this bug.
