Community
Participate
Working Groups
Many people are interested in having JDT's completion showing up on every keystroke (additionally to the usual characters). This is documented on the wiki and suggested on various user media to add `abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ(` to the default `.`. In order to make this user story a bit less annoying, JDT preference page could use a combo with this value pre-set as a suggestion, so enabling content-assist on every keystroke becomes a simpler choice.
New Gerrit change created: https://git.eclipse.org/r/86539
Adding a combo for that corner case is not OK. We can discuss a new preference though.
(In reply to Dani Megert from comment #2) > Adding a combo for that corner case is not OK. We can discuss a new > preference though. The benefit of a combo is that it can be used to propose multiple values, whereas a preference would be only a checkbox, right? If we're sure that there is only one value (abcd...XYZ.(") we'll ever want to propose to users, then a checkbox is indeed fine. However, if we think there are alternatives strategies that are worth proposing to user (such as just `.` or only `.(` or only characters+'.`....) then I believe the combo is the only viable choice.
(In reply to Mickael Istria from comment #3) > The benefit of a combo is that it can be used to propose multiple values, > whereas a preference would be only a checkbox, right? > If we're sure that there is only one value (abcd...XYZ.(") we'll ever want > to propose to users, then a checkbox is indeed fine. However, if we think > there are alternatives strategies that are worth proposing to user (such as > just `.` or only `.(` or only characters+'.`....) then I believe the combo > is the only viable choice. No it is not. At this point it is a new preference. That does not mean we can switch to a combo in the future.
(In reply to Dani Megert from comment #4) > No it is not. At this point it is a new preference. That does not mean we > can switch to a combo in the future. You mean a new preference as a replacement or as an addition? Which classes would be responsible for consuming that preference?
(In reply to Mickael Istria from comment #5) > (In reply to Dani Megert from comment #4) > > No it is not. At this point it is a new preference. That does not mean we > > can switch to a combo in the future. > > You mean a new preference as a replacement or as an addition? Probably an additional one that disables the current one if checked. > Which classes > would be responsible for consuming that preference? Look at the code.
(In reply to Dani Megert from comment #2) > Adding a combo for that corner case is not OK. FYI, it's not a corner-case, and several Java devs I've chat with perceive the automatic completion pop-up on any keystroke as a killer feature when they discover IntelliJ. If you make some search on the web, you'll notice this question is asked pretty often and the answer is about setting this value as combo. > We can discuss a new preference though. As I've been using it for some time, a new preference might be preferable. Indeed, when using completion "continuously as you type" having the '.' character validating the selected proposal is quite annoying. So such new preference should enable completion on every character AND disable auto-select characters at the same time.
(In reply to Dani Megert from comment #2) > Adding a combo for that corner case is not OK. We can discuss a new > preference though. What would the preference be? The thing is that autoactivation on every chars really sucks at the moment: it opens a completion popup with useless info after every keystroke while the list of chars I gave here make pop-up show up in interesting cases only. If in the end, the preference controls the trigger chars, what's wrong with reusing the existing preference to set trigger chars? If what you don't like is having a combo with ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ(" because you think it's ugly, then we can replace it with a label like "greedy auto-activation".
We should bring this to an end during 4.11.
Dani made good suggestions on the patch. However, I think we're limited by the current approach to define trigger chars. Bug 508821 discusses alternative ways of controling auto-activation triggers that would be better for JDT and others.
(In reply to Mickael Istria from comment #10) > Dani made good suggestions on the patch. However, I think we're limited by > the current approach to define trigger chars. Bug 508821 discusses > alternative ways of controling auto-activation triggers that would be better > for JDT and others. I'm not sure we need such a fine-grained approach. My proposal would probably satisfy most use cases.
(In reply to Dani Megert from comment #11) > I'm not sure we need such a fine-grained approach. My proposal would > probably satisfy most use cases. Have you tried auto-activation of content assist after ; or ) pr ] ? It's really something that's not pleasant to use, so we need a way to *exclude* characters from auto-activation. I don't see how to implement this with your proposal and without something like bug 508821
(In reply to Mickael Istria from comment #12) > (In reply to Dani Megert from comment #11) > > I'm not sure we need such a fine-grained approach. My proposal would > > probably satisfy most use cases. > > Have you tried auto-activation of content assist after ; or ) pr ] ? > It's really something that's not pleasant to use, so we need a way to > *exclude* characters from auto-activation. I don't see how to implement this > with your proposal and without something like bug 508821 I think we should just remove some characters (in my proposal) that give a bad experience. Adding API to do is overkill to me.
(In reply to Dani Megert from comment #13) > I think we should just remove some characters (in my proposal) that give a > bad experience. Adding API to do is overkill to me. But as you said, since the list of characters supported by Java identifiers is very long and contains special characters, should we just statically build this list of several thousands characters?
(In reply to Mickael Istria from comment #14) > (In reply to Dani Megert from comment #13) > > I think we should just remove some characters (in my proposal) that give a > > bad experience. Adding API to do is overkill to me. > > But as you said, since the list of characters supported by Java identifiers > is very long and contains special characters, should we just statically > build this list of several thousands characters? No. We would enable auto-activation everywhere and provide a list with excluded characters.
(In reply to Dani Megert from comment #15) > No. We would enable auto-activation everywhere and provide a list with > excluded characters. Which requires a new API too ;)
(In reply to Mickael Istria from comment #16) > (In reply to Dani Megert from comment #15) > > No. We would enable auto-activation everywhere and provide a list with > > excluded characters. > > Which requires a new API too ;) I did not look into the implementation yet to say yes or no.
Given the constraints, it's not something I think I'll work on soon as other bugs seems to have a better effort/value ration to me. If anyone wants to continue this work, that's more than welcome.
Do we even need a combo? IntelliJ has a single checkbox preference "Show suggestestions as you type" - and then simply does the right thing. There's no need for the user to fiddle with a set of activation chars. Can't we do the same and add an "everywhere" checkbox? Which chars are sensible for "everywhere" certainly needs to be tuned carefully, but that set can then be hardcoded IMHO.
(In reply to Julian Honnen from comment #19) > Do we even need a combo? > > IntelliJ has a single checkbox preference "Show suggestestions as you type" > - and then simply does the right thing. There's no need for the user to > fiddle with a set of activation chars. > > Can't we do the same and add an "everywhere" checkbox? +1, sounds good to me. Julian, can you take this bug?
(In reply to Lars Vogel from comment #20) > +1, sounds good to me. Julian, can you take this bug? I don't have time for this ATM.
(In reply to Julian Honnen from comment #19) > [...] > Can't we do the same and add an "everywhere" checkb This is the topic of bug 101420 and as it was discussed here and that other bug, it's not trivial to implement. It's not just a checkbox to add, it's also a ContentAssistant to tweak.
