Bug 353715

Comment 1 Brian Svihovec 2011-12-16 15:15:39 EST

This depends on the EGLDoc theme for .8.

Comment 2 Xiao Bin Chen 2012-01-03 23:37:56 EST

Created attachment 208979 [details]
Draft design for CA additional information

Comment 3 Brian Svihovec 2012-01-04 10:21:49 EST

I believe this line item can be broken down into two tasks, if not more.  

The first task could be to provide more information about each variable or function that is displayed in the content assist window.  For example, in the screen capture from the attached document, each function shows the parameters and return types.  This additional information should be similar to existing Eclipse tools where possible (i.e. Function signatures, field types, etc).  The design document should be expanded to include the details that can be provided for all types of EGL items that can be displayed in the Content Assist window.

The second task, which is dependent on the EGL Doc line item (bug 353524), involves showing EGLDoc information in a pop-up window.  I believe this work is already being covered by bug 367640 and should be removed from this design document.

Comment 4 Xiao Bin Chen 2012-01-05 04:29:54 EST

Created attachment 209057 [details]
CA additional infomation-proposal string design -v0.2

Comment 5 Xiao Bin Chen 2012-01-05 04:32:44 EST

Thanks for your good comment!:)

The second design doc was attached to this workitem.
Please review it.

If there is no problem. I will start to implement it

Thanks.

Comment 6 Brian Svihovec 2012-01-05 14:11:07 EST

Version .2 of the design document looks good so far.

Questions/Comments:
* Are there any performance implications for resolving this extra information?  

* We currently provide the parameters for a function invocation, right?  (i.e. var1 = myFunc(<ca> would list "param1 String in, param2 int) )

* I think we may want to include the package name for primitive types and system defined types.  Technically users will be able to add their own primitive types in the future, and the concept of a System Type should be non-existent.  All types found by content assist will exist only because of the way that EDT has been configured by the user, and nothing should be considered 'special'.  

* I think we should have content assist provide another 'page' of options that consist of Annotations.  This page of options should only be displayed when a user invokes content assist in a place where annotations are valid.  I assume annotations would fall under the 'Types' section of the specification for additional information?

Comment 7 Xiao Bin Chen 2012-01-09 19:54:22 EST

#1> Because most of those information could be retrieved from AST. So, I think manipulating the extra information will not have performance implications.

#2>We do provide the parameters for a function invocation.

#3>You are right, we need to add package information to primitive type or predefined type, which means all types should be treated no different. But I have a questions on this, DO WE NEED TO PROVIDE ICONS FOR THOSE TYPE? If the answer is "yes", CA need the icon. So far, CA just does not use icon for those type.


#4> My understanding is you want to add a new proposal type for ANNOTATION- just like Template, Keyword or Reference type. If the answer is yes, I　will open another enhancement to add a annotation type proposal.

Comment 8 Xiao Bin Chen 2012-01-11 02:35:22 EST

Hi Brian,

I have some problem with the "package" information for primitive types of egl. 

1>Primitive types were defined in "egl.cup", the problem is that there is no package.
I think we could use " - primitive" for this case, or just not use package information for primitive type.


2>System predefined types were hard coding in EGLDataTypeUtility as a String array. We could change the data structure(use other data structure to store the package information) for this enhancement. But I have another suggestion for system predefined types. 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=361699  - [RBD]Content assist need to reflect system predefined type automatically .

Was opened for automatically getting those predefined types from compiler instead of hard code, and after this change, we could get those types binding from enviroment, and CA could get those package information from binding.

Comment 9 Brian Svihovec 2012-01-11 10:18:32 EST

Paul, 

Can you comment on the questions in comment 8?  If the answers are too complicated to put in this defect, we can have a meeting to discuss the issues.

Comment 10 Brian Svihovec 2012-01-11 10:23:45 EST

Xiao Bin,

I agree that we should focus on resolving 361699 instead of creating another hard coded data structure.  Enhancement 361699 fits nicely with our goal of making things more extensible in .8 and removing hard coded values.  I assume there will not be time to implement 361699 in I1, so we should create another enhancement for displaying the package name on System Defined types and mark that as blocked by 361699.

We will look at the I2 plan as I1 is finished, but I believe 361699 should take a high priority for I2.

Comment 11 Brian Svihovec 2012-01-11 10:35:22 EST

Regarding the questions in comment 7:

#3 - I do not think that we need to provide an icon for primitive types

#4 - I tried this on the latest version of EDT, and we are similar to JDT, in that when the user types '@' and then invokes Content Assist, they just get a list of possible annotation types.  I think this is good enough for now, and we do not need to open another enhancement.

Comment 12 Xiao Bin Chen 2012-01-11 21:33:13 EST

https://bugs.eclipse.org/bugs/show_bug.cgi?id=368403 was opened for 
displaying the package name on System Defined types.

So I will not provide package information for primitive types. If you have other good suggestions, just reopen the enhancement.