Bugzilla – Full Text Bug Listing
| Summary: | [content assist] Feasibility of a very flexible content assist w/ JDT | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marcel Bruch <marcel.bruch> |
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daniel_megert, deepakazad, markus.kell.r, remy.suen |
| Version: | 3.8 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Marcel Bruch
I'm not convinced that this is too useful - it looked like chaos to me ;-). Another question will be performance. The completion engine seems to recompute additional/new proposals while typing. This is indeed not planned for our content assistant. I'm pretty sure the user runs into bumps/freezes and the flow of typing will be disturbed. So, my first answer would be "no". I'd have to see this in action before I could say more. Markus, what's your take on this? (In reply to comment #1) > I'm not convinced that this is too useful - it looked like chaos to me ;-). Granted, this completion engine is quite complex and sometimes counter-intuitive :) However, the underlying idea is useful. What I'm basically asking for is: 1. support for non-prefix matching but arbitrary tokens. Another research tool related to this kind of matching is http://www.cs.mcgill.ca/~swevo/explorer/ that basically searches for synonyms of what you have typed and proposed you paths thought the API to the methods you likely want to use. 2. support for dynamic reordering (potentially in progress with bug 350991) 3. support for dynamic addition and removal of proposals. To be clear: It's not a matter of having JDT *implement* these features. I'm asking if you would support changes to the content assist framework to make such tools *possible*. I think it's not too uncommon. Snipmatch (http://snipmatch.com), code recommenders' latest addition, had to invent its own completion engine to make such things work. Sangmok is generally interested to bring Abbreviation Completion to Eclipse. Martin Robillard (API Explorer) can imagine to bring parts of the work in his group to Eclipse, and Cheng Zhang works on an advanced API parameter guessing engine for Eclipse (http://stap.sjtu.edu.cn/~chengzhang/precise/) and is currently stabilizing it for industrial use. I think there is a potential enable exciting and innovative research in Eclipse and take over working ideas into Eclipse JDT or Orion. But there is a need for a platform that supports this. > Another question will be performance. As always. But we do our computations in less than 10 ms. There is more possible than we might expect. In addition, dynamic addition or removal of proposals is only costly if actually used by a completion engine. If JDT's completions don't use them, there will be no penalty. > So, my first answer would be "no". I'd have to see this in action before I > could say more. :) Just to be sure I made my point. I'm not speaking about having "exactly this" completion engine but flexing JDT to support completion engines "like" this one. > Markus, what's your take on this? (In reply to comment #2) > (In reply to comment #1) > > I'm not convinced that this is too useful - it looked like chaos to me ;-). > > Granted, this completion engine is quite complex and sometimes > counter-intuitive :) > > However, the underlying idea is useful. What I'm basically asking for is: > > 1. support for non-prefix matching but arbitrary tokens. This is bug 350000. > 2. support for dynamic reordering (potentially in progress with bug 350991) I guess we can also consider this done. > 3. support for dynamic addition and removal of proposals. Adding is possible via processor. Removing is something we don't want to foster, but you know the tricks to disable a processor ;-). I suggest to close this bug and deal with concrete requests as they arrive. > I suggest to close this bug and deal with concrete requests as they arrive.
+1.
|