Community
Participate
Working Groups
The current configuration options for JDT content assist lists are bit limited. Currently there are two kinds of lists: (i) The 'default' content assist list that shows a combined set of proposals of several completion engines (as configured in Java >> Editor >> Content Assist >> Advanced) and (ii) content assist lists that show the proposals of just one category. I would like to ask JDT team to allow for a more flexible configuration of content assist. The behavior of the 'default' list is great since it allows a user to decide individually which proposal engines he wants to see on the first page. But the subsequent lists allow just one category. Would it be possible to allow users to define any arbitrary number of content assist lists with any combination of proposal engines? This feature would enhance usability in Eclipse in the case of having many code completion engines installed. For instance, Eclipse Code Recommenders currently adds five more completion engines to Eclipse which results in a rather large number of lists to cycle through until you get to the last one. I'll attach a few figures as starting point for as starting points for discussion. Thanks, Marcel
Created attachment 191835 [details] Alternative view on how to configure content assist lists
Created attachment 191838 [details] Second, more compact configuration of content assist
I guess technically it should be doable. Would you be interested in providing a prototype patch?
Yes. Is there a deadline until which the prototype should be ready to be considered for next (3.8) release (I'm assuming that patches for 3.7 are not possible anymore, right?) If 3.8 is targeted: This topic seems perfect for an Eclipse hands-on. I'll see whether I can offer this topic to some students doing a hands-on this semester. If 3.7 may be targeted: I may come up with a prototype patch.
(In reply to comment #4) > Yes. > Is there a deadline until which the prototype should be ready to be considered > for next (3.8) release I think it would be good to have a first prototype patch available by M2 (mid September). Would that work? > (I'm assuming that patches for 3.7 are not possible > anymore, right?) Correct.
(In reply to comment #5) > I think it would be good to have a first prototype patch available by M2 (mid > September). Would that work? Yes. I'll try to give this to a student as a hands-on this semester. If I don't find one until end of April I'll do it myself. I'll come back to this issue with more details after the hands-on kickoff meeting end of April.
Topic assignment for hands-on is done. We have two students working on this topic now. I'm confident that we will come up with a prototype before M2.
Thanks for the updated Marcel.
We have an early version that implements the flexible configuration behavior based on JDT 3.7. What's the best way to get an early feedback on this student implementation? Is a URL to the git repository sufficient for testing?
(In reply to comment #9) > We have an early version that implements the flexible configuration behavior > based on JDT 3.7. > > What's the best way to get an early feedback on this student implementation? Is > a URL to the git repository sufficient for testing? Best would be a patch. We will move to Git this summer but currently we are completely booked with our work for Java 7 support.
Created attachment 199831 [details] Patch for prototype of new content assist lists The two icons "remove_proposal_list.gif" and "remove_proposal_list_over.gif" have to be added to "/icons/full/elcl16" to complete the patch.
Created attachment 199833 [details] Icon needed to complete "org.eclipse.jdt.ui_3.7.1_patch"
Created attachment 199834 [details] Icon needed to complete "org.eclipse.jdt.ui_3.7.1_patch"
Attached is a patch of the current version and two icons that have to be placed in "/icons/full/elcl16". As this will not be the final version, you can get the most recent version from the following git repository: http://vandyk.st.informatik.tu-darmstadt.de:8081/p/students/ep/thomas-content-assist-config There are some incompatibilities with the old implementation. - The internal model changed, so plugins which access this model directly do not work anymore. (e.g. "Java Proposals (Task-Focused)") - The new configuration is stored as an inclusion-list (not as an exclusion-list as before), hence the behavior is slightly different. New proposal engines do not occur in any list by default. Each engine has to be configured explicitly.
Any plans for 3.8?
(In reply to comment #15) > Any plans for 3.8? We at least plan to look at the patch and then we can decide.
Created attachment 201347 [details] New 3.8.0-Patch for prototype of new content assist lists Attached is a new patch that fits the current CVS version and contains some bugfixes, new features and refactorings. The project in the git repository has also been updated to the current "3.8.0"-version (Except for file "org.eclipse.jdt.internal.ui.viewsupport.JavaElementLabelComposer", which contains compilation errors).
Comment on attachment 201347 [details] New 3.8.0-Patch for prototype of new content assist lists set "patch"-flag
Created attachment 202831 [details] patch for an other prototype for the content assist list for Eclipse 3.8 from Freise I am Gerrit, the other person who have worked on a solution for the new content assist list with dnd-functionality. I authored 100% of the content I am contributing (Except sources whose author is Johannes Lerch, as marked in each license header of a class) I have the rights to contribute the content I'm contributing the content under the EPL
(In reply to comment #19) > Created attachment 202831 [details] [diff] > patch for an other prototype for the content assist list for Eclipse 3.8 from > Freise I loaded the patch and looked at the preference page for now (no code review, not tested whether it works when using Content Assist): - A UI which only depends on DnD and/or context menu is not going to make it. On preference pages (dialogs in general) context menus are discouraged and also DnD should only be used when really needed and only as an alternative way to do things. - I could not find a way to choose the proposal kinds for the default proposals as there are no check boxes anymore. There is also no context menu. It looks like I can do multi-selection but that is not stored (and it is not a good replacement for the check boxes). - The page no longer describes what the groups are and when/how they are used. - We don't use "#" as replacement for "number". - We don't use flat look. - (context) menu labels must be in title style. Other things: - When starting a workspace I get this logged: !ENTRY org.eclipse.jdt.ui 4 10001 2012-02-07 14:47:12.767 !MESSAGE preference option missing: org.eclipse.jdt.ui/content_assist_category_order_extended (org.eclipse.jdt.internal.ui.preferences.CodeAssistAdvancedConfigurationBlock) !ENTRY org.eclipse.jdt.ui 4 10001 2012-02-07 14:47:12.775 !MESSAGE preference option missing: org.eclipse.jdt.ui/content_assist_category_order_extended_non_default (org.eclipse.jdt.internal.ui.preferences.CodeAssistAdvancedConfigurationBlock) - CodeAssistAdvancedConfigurationBlock: I guess you accidentally removed the following line: * Copyright (c) 2005, 2011 IBM Corporation and others. - copyright: - Gerrit Hendrik Freise. ==> Gerrit Hendrik Freise and others. - adjust date
(In reply to comment #18) > Comment on attachment 201347 [details] [diff] > New 3.8.0-Patch for prototype of new content assist lists > > set "patch"-flag The relevant parts from comment 20 also apply to this patch. Some additional comments: - Please provide images in an archive with correct folder structure. - Object images go into the 'obj16' folder, not 'ecl16'. - JavaPluginImages is the place to define images. ImageHandler is not needed.
Something I forgot: both patches seem to be pretty big for what the intention is.
The main goal of this request is to choose from all existing proposal kinds in the invocations following the default/first. Hence I don't see the need to have separate UIs for default/first invocation) and subsequent ones. I think the simplest solution would be to have two lists. On the left we have the invocations and on the right we show the check box list of proposal kinds for the invocation currently selected on the left. We'd need some buttons which allow to add and remove (except default/first) invocations. > Something I forgot: both patches seem to be pretty big for what the intention > is. There seems to be many helper / boiler plate types being added, but I might be wrong and they are all needed.
Looks like both students are gone, six months after their patch submission. Given the deadline in two weeks and your requested changes in UI and code, I'm not confident that I can submit a new patch in-time.
(In reply to comment #24) > Looks like both students are gone, six months after their patch submission. > Given the deadline in two weeks and your requested changes in UI and code, I'm > not confident that I can submit a new patch in-time. I agree. I suggest we plan and target for a concrete milestone so that I can put it on the plan and hence also reserve a time slot for it on my side.
