Bug 290627 - Improve code-completion
Summary: Improve code-completion
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: IDE4EDU (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-26 09:46 EDT by Maxime Caron CLA
Modified: 2014-01-09 15:38 EST (History)
1 user (show)

See Also:


Attachments
Burkhard and Keller tree implementation (779.62 KB, application/x-zip-compressed)
2009-10-05 10:08 EDT, Maxime Caron CLA
no flags Details
This is the change needed to be able to custumize the code-completion behavior (47.67 KB, application/x-zip-compressed)
2009-10-06 23:24 EDT, Maxime Caron CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Caron CLA 2009-09-26 09:46:04 EDT
The idea is that when what you are typing is not a prefix of anything
the code-completion popup should not disappear but stay visible.
Also we can do a fuzzy search using levenshtein distance if the prefix search have found nothing.
Comment 1 Maxime Caron CLA 2009-10-05 10:08:46 EDT
Created attachment 148777 [details]
Burkhard and Keller tree implementation

This is my implementation of a BK-tree.
BK-tree is a index accelerate approximate string matching.

The idea come from 
* Some approaches to best-match file searching
http://portal.acm.org/citation.cfm?id=362003.362025
* Fast Approximate String Matching in a Dictionary (1998)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.21.3317&rep=rep1&type=pdf
Comment 2 Maxime Caron CLA 2009-10-06 23:24:11 EDT
Created attachment 148957 [details]
This is the change needed to be able to custumize the code-completion behavior

What this change does is that when the CompletionProposalPopup is open and we type somehting that return no result the filter will not close the popup.

This is added as a customizable ContentAssistant preference.
It's also disactivated by default.
Comment 3 Wayne Beaton CLA 2010-02-03 13:00:55 EST
I'm not quite sure what to do with this bug. It certainly is cool, but to use it would require that we make a significant fork of JDT. Ultimately, that may be inevitable, but it's not something we can enter lightly. Creating a fork introduces a significant maintenance burden: as new versions of the JDT come out, we would have to reapply these changes and hope that we understand enough about the technology to make it work. This is certainly something we'd have to stay on top of. Again, I'm not saying that we will never do this, I'm saying that I'm not ready to at this point.

Having said all this, I'm pretty sure that the Mylyn project has sorted out how to extend this functionality without forking anything. It makes sense to me that we should spend some effort looking there before any decisions are made.
Comment 4 Maxime Caron CLA 2010-02-03 17:21:25 EST
(In reply to comment #3)
> I'm not quite sure what to do with this bug. It certainly is cool, but to use
> it would require that we make a significant fork of JDT. Ultimately, that may
> be inevitable, but it's not something we can enter lightly. Creating a fork
> introduces a significant maintenance burden: as new versions of the JDT come
> out, we would have to reapply these changes and hope that we understand enough
> about the technology to make it work. This is certainly something we'd have to
> stay on top of. Again, I'm not saying that we will never do this, I'm saying
> that I'm not ready to at this point.
> 
> Having said all this, I'm pretty sure that the Mylyn project has sorted out how
> to extend this functionality without forking anything. It makes sense to me
> that we should spend some effort looking there before any decisions are made.

is it possible to push the path that allow the user to customize the Auto-complete behavior to the main jdt branch.

And keep the Burkhard and Keller tree in scheme4edu.

I am pretty sure that standard user would appreciate being allowed to customize the code editor behavior a little bit more.
Comment 5 Wayne Beaton CLA 2010-02-03 22:50:31 EST
(In reply to comment #4)
> I am pretty sure that standard user would appreciate being allowed to customize
> the code editor behavior a little bit more.

Actually, I think that the "standard user" would be horrified by the mere concept. However, I agree in principle that customization in the code editor is a good thing in the hands of a plug-in developer. I know, minor nit.

My last point in comment #3 was meant to say that I believe that this particular aspect of the Java editor _is_ customizable and that the Mylyn project is currently exploiting that ability. Or they're doing something else. It's worth investigating to see what they've done.
Comment 6 Maxime Caron CLA 2010-03-01 12:54:55 EST
> My last point in comment #3 was meant to say that I believe that this
> particular aspect of the Java editor _is_ customizable and that the Mylyn
> project is currently exploiting that ability. Or they're doing something else.
> It's worth investigating to see what they've done.

I will be happy to investigate others way to integrate this feature  without modifying the JDT editor code. 

Could you please point me to a feature of Mylyn you think i should have a look at that you think are exploiting that ability.  Or put me in contact with someone who can.
Comment 7 Wayne Beaton CLA 2010-03-03 08:20:27 EST
I would start looking in the org.eclipse.mylyn.java.ui bundle. After that, a well-worded question on the Mylyn forum [1] should result in some help.

[1] http://eclipse.org/forums/eclipse.tools.mylyn