Bugzilla – Full Text Bug Listing
| Summary: | System libraries not in content assist | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | broy2 | ||||||||||
| Component: | EDT | Assignee: | Xiao Bin Chen <xiaobinc> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | chenzhh, jinfahua, jqian, pharmon, svihovec, xiaobinc | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
broy2
Hi Theresa: In edt, paul is removing those libraries and moving to the types. So those library(except strlib) are not show in the list. The new design need to base on paul's work. Thanks Hi paul. Currently,system libraries are externaltype xxx type nativetype xxx.. And in rbd, all system libraries are library xxx... So the systemlibrarymanager can't return those system libraries. Hi,Branda: Because those system library in EDT are changed to external type. So they are not "system libraries" at least in edt 0.7.0 This needs to be fixed! (In reply to comment #4) > This needs to be fixed! Actually, I have forward one email to you and other guys, If we need to fix this defect. Paul need to do some thing for this. Because those part are not "libraries" any more, If we need to add this to content assist, something must be provided to mark it as a system library,otherwise, they can't be regard as system libraries. xiaobin. Hi paul could you give some comment on this defect? If we feels these libraries(or external types) are important enough that we always want it to be proposed when user press Ctrl+Space in a new line, we should make it appear. If they are not system libraries any more, and is not handled by our system library proposal, we should create other proposals to handle this. The problem is how do we know this externaltype xxxx end is a system libraries or not,So I think may be we need some underlay support on this requirement. (In reply to comment #6) > If we feels these libraries(or external types) are important enough that we > always want it to be proposed when user press Ctrl+Space in a new line, we > should make it appear. If they are not system libraries any more, and is not > handled by our system library proposal, we should create other proposals to > handle this. From user's point of view, content assist needs to provide these hints. So it is important to fix this. I can think of 2 ways that we can change this to work: 1) Add an annotation to the ExternalTypes that we want to have proposals for in content assist. We could name this annotation something like @ContentAssist (this is kind of similar to the @VEProperty annotation, in that it is an annotation that will affect an editor). Any ExternalTypes (or handler or whatever part we want) with this annotation would be offered as a proposal when content assist is invoked. SystemEnvironment would need some minor modifications to accumulate and return this set of parts. 2) As Matt suggested in a note, we could add an API to the compiler to allow the compiler to register a set of part names that would be offered as content assist proposals. In the future we could add an extension point to allow users to register additional part names. Either way is fairly inexpensive to implement. Currently, I think i prefer the annotaton. Created attachment 203997 [details]
patch for ca list system libraries
Created attachment 203998 [details]
The system .eglar file
Hi paul, I have made a patch for this defect. I choose the first solution you mentiond. Could you help me to review this patch? thanks... I am ok with the changes made to the system part definitions. However, I am NOT ok with the changes to SystemLibraryManager (and to SystemEnvironment). The new annotation should ONLY affect content assist. It should not affect how system data is resolved. With the changes you have made, the data and functions in the system external types would be able to be resolved even if they are not qualified. This is not acceptable (and currently not supported by our IR generation code). The external types that contain the @ContentAssist should be kept in a separate map, and should not be in the libraries map in SystemLibraryManager. The data and functions from these externalTypes should NOT be added to the libraryData and libraryFunctions map. I am ok with processing this information and storing it in some other maps, for use by content assist. In my opinion, the first priority for these libraries in regards to Content Assist (CA) should be to show the ExternalType names when CA is invoked (on a blank line). So, for example, I should see: HttpLib JsonLib StringLib etc... The second priority would be to show the functions/fields in these ExternalTypes. However, if one of these fuctions/fields is selected, CA should automatically fully qualify it with the exernal type name. For example, if I type: write then press content assist, i should see: writeStdOut writeStdErr offerred as a proposal. If I select it the first one, content assist should replace my string with: SysLib.writStdOut() It is vitally important that the changes that you make for this do NOT affect how system parts are resolved. Because of this, it is best to keep the changes made to SystemEnvironment and SystemLibraryManager completely separate from the current code. I would suggest making a new ContentAssistPartmManager to hold the parts that are flagged with @ContentAssist. This new class should only be referenced by SystemEnvironment (to add the parts) and by the ContentAssist code. Created attachment 204047 [details]
new_patch after paul's comment
Created attachment 204048 [details]
eglar file
Hi paul, thanks for you good comments. new patch was provided. One thing I should mentioned is: In edt if you did not input anything in the editor, CA will not show those system libraries field or functions.(which behavior in RBD) CA will just list those system libraries. Because too much selection listed in CA list will be harder for users to select the thing they want. If user type something in the editor CA will retrieve those system libraries' field and functions in the CA list like if you invoke content assist here function aa() invoke here. end Content Assist will just list those system libraries like sysLib mathLib dateTimeLib etc. But if you invoke after you input something function aa() write//invoke here end Content assist will list writeStdOut writeStdErr the following is just work like RBD. Xiaobin fixed Great changes! Thank you NOTE: The following changes should not be considered at this time, but should be re-visited after .7 ships, or after the critical defects in .7 have been resolved. [Unless my proposals result in a major design change, which I don't think should happen] I talked with Paul Harmon about this today, and I believe we should attempt to resolve this issue without the addition of a new ContentAssist annotation. Based on my conversation with Paul, the problem is that we are not proposing 'singleton' External Types on a blank line when a user invokes content assist, and the ContentAssist annotation indicates that the System External Types (e.g. MathLib, etc) should be displayed as a proposal. My first question was to ask how this would work if I defined my own External Type with a private constructor in an EGL project, which means that it is a 'singleton'. I believe our solution for System External Types should be the same as the one we would use for User defined External Types. When a user invokes content assist on a blank line, any External Type with a private constructor, either defined by the user or defined by the system, should be displayed as an option. A subtle change in this proposal, in addition to the removal of the ContentAssist annotation, is that we should no longer store a ContentAssistManager in the System Environment. I do not believe that the System Environment, which can be used outside of the IDE, should 'know about' IDE related classes. Hopefully we can just re-use some of the existing models that are already used in the IDE to provide content assist proposals based on User defined parts, but I would be ok with re-using ContentAssistManager in an IDE only plug-in if that is what is required. Finally, there are additional considerations for showing External Types on a blank line in content assist, which can be tracked as part of this defect or in a new defect: * External types should be proposed on a blank line if the part contains 'static' functions, even when the constructor is not private. * When a user chooses an External Type from content assist on a blank line, a variable should not be created by default (e.g. var1 TheExternalType;). This allows the user to directly invoke functions on the type (e.g. TheExternalType.doSomething();) One additional thing to keep in mind. Different compilers may use a different set of system parts. If content assist caches information about system parts, it will need to associate this with the particular compiler being used. Do you guys want me to leave this open for the future changes or close it? The original bug has been fixed. Verified. Hi, brian: a new defect was opened to track the problem you mentioned. https://bugs.eclipse.org/bugs/show_bug.cgi?id=360755 |