groovy
Cannot easily type an Enum range when "Enable auto activation" for code assist is enabled
Another case similar to #676.
Consider this enumeration:
package test33;
public enum MyEnum {
FOO, BAR;
}
And assume you want to type this:
package test33
class Test33 {
void foo() {
(MyEnum.FOO..MyEnum.BAR).each {
}
}
}
When you start to type (MyEnum.FOO. and then you hit the second dot, this is what gets inserted: (MyEnum.FOO.BAR..
I see two problems here:
- in general, having code assist propose BAR when you are at
MyEnum.FOO.doesn't make sense to me (this happens even outside the range context) - I still think
.as a triggering character should simply be disabled whenever preceded by another dot, as discussed in #676.
I disable . as a trigger if completion expression ends with dot and contains no other dot. In this instance, you have an additional dot in the expression; . trigger exists to be able to add part of a path expression and immediately go to completion proposals for the next path segment.
You can type Esc to disable proposals at any time.
I see, but AFAIK there's no possibility in a path expression to have .., so I'm still convinced that there's no practical case in which treating . as a triggering character when it's preceded by another . is useful. Please correct me if I'm wrong. Do you have any example of the contrary?
The problem of using Esc here and in #699 is that you realise you had to press Esc when it's too late and the editor has already inserted the wrong thing for you. Unless you have a very strong memory and you know in advance whenever you have to press Esc...
Type foo. and get completions for bar, etc. Then type . to get foo.bar. and get proposals for baz, etc.
It's difficult to balance/predict the desire to type a range vs. type a path expression. If you use auto-activation, cancelling out of it should be part of your habits in Groovy. There are so many variations.
But I meant "when it's IMMEDIATELY preceded by another .". That is, if you try to type .. (by typing . and then pressing the dot key again), the second dot key press should NOT trigger the completion. This would solve this issue and any similar one I think.
That is the same scenario as I mentioned for completing foo.bar.baz. You don't need to type anything but .. starting from foo.
I get it; your intent is to type a range. But what I am saying is another user has the intent of typing a path sequence for the exact same keystrokes.
Ok, I got it, you're talking about the very lucky case in which the first proposal is always correct and you can type foo.bar.baz by just typing dot several times... Hmmm... I must think about this some more...
I was wondering how the vararg method declaration is handled. I mean, if you want to type:
void doSomething(String... args) {
}
When you type "String...":
- you don't get any meaningful code assist suggestion after the first "." (there are basic proposals like "abstract", "def", "final"): IMHO all (or at least most) of these suggestions are wrong, in any case when you type the second "dot" no selection from this list is made (i.e.: the dot is not considered a trigger character), so you get "String.." correctly, with no interference
- no hint is given after you have typed the second dot
- suggestions appear again after you have typed the third dot
Is this case handled in a special way? Can this inspire how to fix the range case?
When completing a vararg type, the completion context is usually "method" or if your're seeing modifier keywords, it's "class body". The keywords and types proposals use a different set of triggers. https://github.com/groovy/groovy-eclipse/blob/master/ide/org.codehaus.groovy.eclipse.codeassist.completion/src/org/codehaus/groovy/eclipse/codeassist/ProposalUtils.java#L58
When you have def m(String..) {}, current parser recovery creates a property named "def". This is designed for the case where you are starting to type something in between class members. There is no recovery for a malformed parameter list at the moment.