Bugzilla – Full Text Bug Listing
| Summary: | [misc] Assignment via Code Recommenders | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Lars Vogel <Lars.Vogel> | ||||
| Component: | Recommenders | Assignee: | Marcel Bruch <marcel.bruch> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P5 | CC: | deepakazad, eclipse.phc5x, markus.kell.r | ||||
| Version: | unspecified | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Lars Vogel
To me it looks like that with this proposal we are getting very close to features that should be part of JDT rather than Code Recommenders (not arguing against its usefulness). Sure, we can state this as a subwords problem (propose quick fixes if only a subset of completion text ist already given). But I'm a bit scared that all this may end up in adding lots of redundancies (read reimplementing and/or copy and pasting JDT code) to make this happen. If you continue your list of things you would like to see, what else is in the box? ;) Maybe it makes sense to collect all potential ideas and discuss them with the jdt.ui team? We may be able to find a better solution that would not end up in that much redundancy. FWIW, Sebastian and me have a "Variable Definition Recommender" in mind (odd naming yet but anyways). The idea is: You enter IEditorPart p = |^Space and it returns you a list of potential, and most likely right-hand-sides for the given type on the left and current context. In that sense, we are not that far away from a real Code Recommender ;) I agree that would be more a JDT feature. Perhaps Ctrl+Template selection could do an assignment. Whenever something goes into the box, I open a bug. Hence my code recommender box is currently empty. ;-) (In reply to comment #2) > Whenever something goes into the box, I open a bug. Excellent ;) (In reply to comment #1)> > FWIW, Sebastian and me have a "Variable Definition Recommender" in mind (odd > naming yet but anyways). The idea is: > > You enter IEditorPart p = |^Space and it returns you a list of potential, and > most likely right-hand-sides for the given type on the left and current > context. In that sense, we are not that far away from a real Code Recommender > ;) This is the kind of feature I've been looking for a long time. I'm thinking about those cases where you have multiple ways of assigning a new variable, for instance: Display d = Display.getDefault(); Display d = PlatformUI.getWorkbench().getDisplay(); and so on. I'd like to know If there's a way I could contribute to Recommenders since I'm very interested in the project and I'm currently using it. Basically, as a starting point, I'll be rising bugs as soon as I'll find them :) > As a starting point, I'll be rising bugs as soon as I'll find them :) That's a perfect start :) (In reply to comment #4) > I'm thinking about those cases where you have multiple ways of assigning a > new variable, for instance: > > Display d = Display.getDefault(); > Display d = PlatformUI.getWorkbench().getDisplay(); > > and so on. > I'd like to know If there's a way I could contribute to Recommenders since I'm > very interested in the project and I'm currently using it. I assume you know Recommenders' chain completion [1] already which *partially* adresses this issue. To make this 'definition recommender' work, we need to collect a few statistics about how objects of a certain type (say, a Display or IWorkbenchHelpSystem etc.) are *typically* defined. As a quick starter, I think we should do the following: Import a few plugin projects into your runtime workspace (e.g., org.eclipse.pde.ui, org.eclipse.jdt.core/ui), write a simple analyzer that analyzes all source files of this workspace and dumps all ways how, for instance, variables of type Display are typically assigned in the code. Next, we need to aggregate these results a bit and could then, as a first step, create a simple extdoc provider that shows the most frequently used ways how to obtain such an instance inside recommenders extended javadoc view. After that we should know enough about the data and should be able to create a new quick fix assistant that proposes such things based on the data we've collected before. What do you think? Are you familiar with JDT 's AST API and would you like to create such a basic AST analyzer that extracts common assignments for a given type and create some statistics from that data? [1] http://eclipse.org/recommenders/documentation/usr.html#d0e280 (In reply to comment #0) > getActiv -> Suggestions > > getActivitiy() > getActivity() - with assignment Definite possibility. My only concern is that this way will right away double the number of proposals, and in cases where the number of suggestions is even moderately large the total number of proposals may explode. In content assist, you can toggle 'insertion' and 'over-write' behavior by pressing 'Ctrl' while selecting a proposal. Maybe a similar trick to also insert the LHS could be explored. But then such tricks are also hard to discover for users. (In reply to comment #5) > What do you think? Are you familiar with JDT 's AST API and would you like to > create such a basic AST analyzer that extracts common assignments for a given > type and create some statistics from that data? Sure! I think it's a good starting point, I'll have a look at it. (In reply to comment #6) > Definite possibility. My only concern is that this way will right away double > the number of proposals, and in cases where the number of suggestions is even > moderately large the total number of proposals may explode. Well this actually happens for the "Java subwords Proposals" as well. If you enable both basic Java and Subwords proposals, duplicate results are displayed in the default list. Using different proposal computers, the user can just disable the java proposals in the default list, and this could be the same approach for "Assignment proposals". (In reply to comment #8) > Well this actually happens for the "Java subwords Proposals" as well. If you > enable both basic Java and Subwords proposals, duplicate results are displayed > in the default list. I think the duplication is (forcibly) removed in the latest builds. > Using different proposal computers, the user can just > disable the java proposals in the default list, and this could be the same > approach for "Assignment proposals". IMHO adding another proposal computer would NOT be a great solution in this case. How about an 'auto-assist'? The idea is when you insert a proposal like getActivity() on an empty line, the quick assist popup - with only 'Assign to local variable' quick assist - can be automatically shown and the user just has to press enter to select the quick assist, or press esc to make the auto-assist go away. (We already do something similar in properties editor when you paste a string that contains '\' chars - there you get an auto-assist to escape '\' chars.) I think we are discussing two different tools ATM. Lars proposed having content assist that completes getAc$ --> > getActivitiy() > getActivity() - with assignment Massimo is discussing an advanced form of chain completion + call completion - maybe event with likelihoods with a LHS already given: Display d = $ --> then may be completed to: > Display d = Display.getDefault() - 65% ; > Display d = PlatformUI.getWorkbench().getDisplay() - 15%; > Display d = new Display(shell)) - 5%; I'm with Deepak's concerns for Lars' proposal. I see no problem with Massimo's approach ATM - which also could be implemented as quick fix or quick assist. I've no particular feelings at the moment about this :) I'm just curios to see some data that proves that we can make such a completion happen with a reasonable quality and performance. (In reply to comment #10) > How about an 'auto-assist'? > > The idea is when you insert a proposal like getActivity() on an empty line, the > quick assist popup - with only 'Assign to local variable' quick assist - can be > automatically shown and the user just has to press enter to select the quick > assist, or press esc to make the auto-assist go away. Seems worth trying. if a user continues writing with a '.' the popup could simply go away. Lars, what do you think? (In reply to comment #9) > (In reply to comment #8) > > Well this actually happens for the "Java subwords Proposals" as well. If you > > enable both basic Java and Subwords proposals, duplicate results are displayed > > in the default list. > I think the duplication is (forcibly) removed in the latest builds. Yes. Please update to latest 1.0.0 RC build available from dev update site and open a bug if you can see both engines make proposals at the same time :) > > Using different proposal computers, the user can just > > disable the java proposals in the default list, and this could be the same > > approach for "Assignment proposals". > IMHO adding another proposal computer would NOT be a great solution in this > case. I think so too. Adding duplicated proposals should only be used sparsely. For Lars use case I think quick assist may work well. For cases where the LHS is already given, I see no sever problem since the proposals we would make are probably quite different from those JDT would make. So, I hoped I catched up with all discussion subthreads now. > The idea is when you insert a proposal like getActivity() on an empty line, the
> quick assist popup - with only 'Assign to local variable' quick assist - can be
> automatically shown and the user just has to press enter to select the quick
> assist, or press esc to make the auto-assist go away.
-> Sounds great, pressing Enter sounds like a good user interaction for this assignment. I think with this feature, we are better then IntelliJ in variable assignment.
(In reply to comment #10) > How about an 'auto-assist'? > > The idea is when you insert a proposal like getActivity() on an empty line, the > quick assist popup - with only 'Assign to local variable' quick assist - can be > automatically shown and the user just has to press enter to select the quick > assist, or press esc to make the auto-assist go away. I thought about this a bit more and also discussed this with Markus. Some points that came up... 1. In case the method takes a parameter we already show a popup with parameter hints, this will complicate things. 2. There is a risk that we might start showing auto-assists in too many places or a user may not want to see them. Probably, a user should be able turn off all auto-assists via a single preference. 3. We have to be careful that auto-assist doesn't interfere with normal typing. I guess we need a prototype to see how auto-assist feels in this situation. (In reply to comment #15) > I guess we need a prototype to see how auto-assist feels in this situation. I've no feeling of how complex such a prototype would be as I don't know which classes/extensions are involved. Do you have pointers? How long do you think would prototyping take for a JDT-external? Created attachment 217466 [details]
Assignments analyzer plug-in
(In reply to comment #5) > What do you think? Are you familiar with JDT 's AST API and would you like to > create such a basic AST analyzer that extracts common assignments for a given > type and create some statistics from that data? Here it is. I attached a zip containing the source and binary exports of a plugin that simply scan the whole workspace for assignment/variable declaration expressions of the specified type. The plugin adds a new icon on the main toolbar (it's the same icon of the "Variables" tab in the debug perspective). To perform a scan, select a type in a java editor and click the tool icon, at the end of the scan job a dialog should appear displaying the results. The displayed statistics are just to give you an overall of the results, but as you will notice not all the results are "interesting" for the user. Hope this is what you were looking for, of course this can be improved and any suggestion is welcome! If you think it's worth it, I can open another bug on this subject since I think that discussing here is a bit confusing. (In reply to comment #18) > To perform a scan, select a type in a java editor and click the tool icon, at > the end of the scan job a dialog should appear displaying the results. The > displayed statistics are just to give you an overall of the results, but as you > will notice not all the results are "interesting" for the user. Thanks. I gave it a spin but had some problems to get results. I triggered it on Matcher, IWorkbenchWindow, and PlatformUI with the snippet below. For the latter two I got an exception (see below); for the first one it analyzed lots of compilationUnits but the popup at the end was shown only a very short time (400ms or so) and then disappeared. I had no chance to see what it would recommend. Any ideas how to fix these issues? public void m() { Pattern p = Pattern.compile(""); Matcher matcher = p.matcher(null); String string = matcher.group(0); boolean z = matcher.matches(); IWorkbenchWindow w = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); // Matcher matcher = p.matcher(null); // matcher. } // java.lang.IllegalArgumentException: ??? at org.eclipse.recommenders.utils.Throws.throwIllegalArgumentException(Throws.java:25) at org.eclipse.recommenders.utils.Checks.ensureIsNotNull(Checks.java:189) at org.eclipse.recommenders.utils.Checks.ensureIsNotNull(Checks.java:184) at org.eclipse.recommenders.utils.rcp.JdtUtils.isAssignable(JdtUtils.java:502) at org.eclipse.recommenders.completion.rcp.internal.assignments.visitor.AssignmentExpressionVisitor.processExpression(AssignmentExpressionVisitor.java:81) at org.eclipse.recommenders.completion.rcp.internal.assignments.visitor.AssignmentExpressionVisitor.visit(AssignmentExpressionVisitor.java:54) at org.eclipse.jdt.core.dom.VariableDeclarationFragment.accept0(VariableDeclarationFragment.java:221) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.FieldDeclaration.accept0(FieldDeclaration.java:287) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514) at org.eclipse.recommenders.completion.rcp.assignments.AssignmentExpressionAnalyzer.analyzeCompilationUnit(AssignmentExpressionAnalyzer.java:121) at org.eclipse.recommenders.completion.rcp.assignments.AssignmentExpressionAnalyzer.analyzePackageFragment(AssignmentExpressionAnalyzer.java:105) at org.eclipse.recommenders.completion.rcp.assignments.AssignmentExpressionAnalyzer.analyzeProject(AssignmentExpressionAnalyzer.java:87) at org.eclipse.recommenders.completion.rcp.assignments.AssignmentExpressionAnalyzer.analyze(AssignmentExpressionAnalyzer.java:64) at org.eclipse.recommenders.completion.rcp.internal.assignments.handler.AnalyzeAssignmentsHandler$1.run(AnalyzeAssignmentsHandler.java:74) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) (In reply to comment #19) > Thanks. I gave it a spin but had some problems to get results. I triggered it > on Matcher, IWorkbenchWindow, and PlatformUI with the snippet below. For the > latter two I got an exception (see below); for the first one it analyzed lots > of compilationUnits but the popup at the end was shown only a very short time > (400ms or so) and then disappeared. I had no chance to see what it would > recommend. For the exception part that's my fault, I missed a null check when finding the IType on a project, but the strange thing is actually the dialog disappearing. It's a dialog I'm opening at the end of the job and it should remain visible until OK/Cancel is pressed. Could you provide me with some details on your setup like Eclipse version and OS? In the meanwhile I'm fixing the AssignmentExpressionAnalyzer to take care of the NPE. (In reply to comment #20) > Could you provide me with some details on your setup like Eclipse version and > OS? In the meanwhile I'm fixing the AssignmentExpressionAnalyzer to take care > of the NPE. How about publishing the plug-in project directly to Gerrit? Then I could quickly checkout an debug the code and provide little more information? (In reply to comment #21) > How about publishing the plug-in project directly to Gerrit? Then I could > quickly checkout an debug the code and provide little more information? Sounds good! I just set up my Gerrit account and I'm currently watching the recommenders project. I'm going through reading the wiki on the contribution process so hopefully this evening I'm ready to commit for review. Any hint you may want to give me is welcome since I'm pretty new to the contribution process :) As we don't have our own page for gerrit yet (and are working towards a common page for all projects rather then many project-specific ones): I hope the Egit/JGit page helps to get you going. Just replace the paths specific to Egit with ours: http://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches https://git.eclipse.org/r/#/c/6428/ I assert that I: 1. authored 100% the content they are contributing 2. have the rights to donate the content to Eclipse 3. contribute the content under the EPL Rescheduling this feature for discussion for 2.0 planning. The initial feature request belongs to JDT rather than Recommenders. The chain completion idea of Massimo was abandoned. Closing as wont fix at the moment. |