Community
Participate
Working Groups
Currently the first ILanguage that is discovered for a given content type is used, and there is no way for an ISV nor a user to specify what ILanguage they wish to use. We need a mechanism whereby ISVs can specify for their toolchain which ILanguage they want, and also a mechanism whereby users can specify the "language variant". Language variant can be intimately tied to build settings. E.g. some compilers have options which allow the user to specify "Strict ANSI Mode" or "Embedded C++" or "C99 Standard", etc. Thus, it is even possible that on a per file basis the language variant might change.
This is covered by the New Project Model Design. See bug#115935 and design attached to that bugzilla: https://bugs.eclipse.org/bugs/attachment.cgi?id=46637 Mikhail
Hi Chris, Could you elaborate a bit more on this enhancement request? I'm asking because the "content type<->language" association mechanism is actually covered by the New Project Model (see bug#115935 and design attached to that bugzilla: https://bugs.eclipse.org/bugs/attachment.cgi?id=46637). Are you going to propose some different approach of handling the "content type<->language" association? ..adding the core inbox to the CC-list so that other Core developers be in synch with the discussion. Thanks, Mikhail
(In reply to comment #2) > Hi Chris, > Could you elaborate a bit more on this enhancement request? I'm asking because > the "content type<->language" association mechanism is actually covered by the > New Project Model What if I don't have a CDT project though?
Right now, the parsing used for indexing is kicked off from an ILanguage object which we currently find based on contentType and with the assumption that it's GCC. With the new project model, we should be able to have fancier ways of getting the ILanguage object based on toolchains and such. Now we've always supplied these parsing routines the ICProject and/or ITranslationUnit of the file to allow us to get at the build information. We should also be able to use the new project model here to get us config specific build settings as well. If you are parsing outside of the context of an ICProject, then you must have some other way of getting build information to the parser. Also, you still need someway to get the index object into a PDOM that is associated with an ICProject for any of the features that use the index to work.
Created attachment 56336 [details] initial design document Initial design for proposed changes attached.
The proposal looks good to me. One question, though: The screenshot in your document shows how to select a language for an individual file. Are you going to provide a different property page for folders and projects? For those, I'd expect to be able to select a language per content-type.
Has anyone thought about how this could be relevant to assembly files? The problem here is that there may be several assembly dialects (x86, arm etc.) in files with the same extension (e.g. *.asm). At current there is no mechanism for adding assembly dialects in a standard way. We have implemented an assembly editor (syntax highlighting, tab conversion etc.) in an ad hoc way on top of the existing (rather sparse) functionality, but this only works for a single assembly variant. It would be nice to have an editor capable of handling more than one assembly variant. Probably this belongs in a separate enhancement req. but thought I'd mention it here since the problems are clearly related and it would be nice not to have to re-implement or retrofit a solution after this work has been done.
(In reply to comment #6) > The proposal looks good to me. > One question, though: > The screenshot in your document shows how to select a language for an individual > file. Are you going to provide a different property page for > folders and projects? For those, I'd expect to be able to select a > language per content-type. Yes, sorry, we should have spelled it out explicitly. The GUI that Mikhail already proposed in the new project model will suffice for that, which was why we omitted it from the document. Take a look at his slides from the Fall Summit.
I have a couple of questions/comments: 1. Is there a Functional Requirements missing? "Users must be able to select a language choice on a per project configuration basis using the Eclipse properties mechanism." This is important because different configurations coiuld use different tool-chains and conditional compilation could be used to use a different language variant with a different tool-chain. Or, is the word Configuration missing from R3? 2. I would think that most of the inquiries for a language given a file will need to answered in the context of a configuration - most often the active configuration. Is the Language Manager going to understand Configurations - I don't remember what/if Mikhail's design has to say about that? In any case, I think there should be an API where the configuration is passed into the inquiry. For example, we need to be able to build configurations without switching the active configuration. Leo
(In reply to comment #9) > I have a couple of questions/comments: > 1. Is there a Functional Requirements missing? > "Users must be able to select a language choice on a per project configuration > basis using the Eclipse properties mechanism." > This is important because different configurations coiuld use different > tool-chains and conditional compilation could be used to use a different > language variant with a different tool-chain. > Or, is the word Configuration missing from R3? > 2. I would think that most of the inquiries for a language given a file will > need to answered in the context of a configuration - most often the active > configuration. Is the Language Manager going to understand Configurations - I > don't remember what/if Mikhail's design has to say about that? In any case, I > think there should be an API where the configuration is passed into the inquiry. > For example, we need to be able to build configurations without switching the > active configuration. > Leo Yes, quite right. We actually noticed a while ago that was missing and I guess we forgot to put it in, but it is our intent to do as you describe. Thanks for catching that, we'll update the document soon.
Jay and I have been working on this in tandem. I'm doing a small checkin which only does enough for us to test our C99 parser. Right now you can specify project level mappings and this will override the content type settings. The mappings are persisted as a project preference. I had to add a method to ILanguage so that each language would have a human readable display name suitable for display in the UI. This will mean that current clients of ILanguage will have to add this method to their implementations. I could have deprecated ILanguage and created an ILanguage2 for this purpose but I felt that for such a trivial change it was rather senseless and assumed it would not be burdensome for ILanguage clients to adapt to this change. If anyone has issues with this please advise. The next step is to implement a language change notification mechanism in the language manager and have all the clients register for and handle these notifications. Right now none of the language clients will get updated when the language changes, so reindexing won't happen, syntax highlighting won't update, etc. If you manually trigger these changes you can see the change in language reflected.
I would like to add minimal write support to the LanguageManager to be able to configure a language mapping programmatically. Something like: /** Associate a content type with a language on project level, or remove the association, if the languageId is null. */ public void setLanguageForContentType(IProject project, String contentTypeId, String languageId) Otherwise there is no possibility to get (public) write access to the language mappings.
Hi Toni, There's a way to programmatically set the project-language mappings: LanguageMappingConfiguration config = LanguageManager.getLanguageMappingConfiguration(project); config.addProjectMapping(contentTypeId, languageId); // Write it out to .cproject LanguageManager.storeLanguageMappingConfiguration(project); Is this the sort of API you're looking for? Or would you prefer to add a convenience method to LanguageManager?
Yes, I noticed that, but the class LanguageMappingConfiguration is not public and I suppose it is not meant to be public API.
We can make that functionality API. We intended that class to be the single place where language mappings are assigned.
(In reply to comment #15) > We can make that functionality API. We intended that class to be the single > place where language mappings are assigned. OK, that would be great.
I've opened bug 179098 to cover the API change. I'll be posting a patch there soon. (In reply to comment #16) > (In reply to comment #15) > > We can make that functionality API. We intended that class to be the single > > place where language mappings are assigned. > > OK, that would be great. >
Since there is a need to programmatically change language mappings, this work (or at the very least, its APIs) should be included as part of M6. Since Chris is away this week, I'll be continuing his work on this bug. The remaining items are language mapping change notifications (e.g. to trigger reindexing), workspace-wide and file-specific mappings. I expect to post a patch within the next day or so. Toni, would you mind taking a look at the patch to see if it fits your needs?
Created attachment 62293 [details] Remaining changes for language extensibility support I've added APIs for programmatically changing file-level mappings and workspace-level content type mappings. To make the API clearer, I've changed the names of the APIs dealing with project-level content type mappings. To summarize, the patch contains these API changes: 1. Renamed LanguageMappingConfiguration to ProjectLanguageConfiguration. 2. Added WorkspaceLanguageConfiguration as API for manipulating workspace language mappings. 3. Added file-level mappings to ProjectLanguageConfiguration. 4. Added language mapping notification capabilities to LanguageManager. ... and these non-API changes: 5. Implemented language mapping notifications to the PDOM to trigger reindexing where appropriate. 6. Added preference page for setting workspace language mappings. 7. Added property page for setting file-level language mappings. 8. Added serialization/deserialization for workspace and file-level mappings.
Toni, could you look over the API changes I made to see if I'm missing anything you might need? I'd like to get at least the API changes in for M6, but since Chris is away this week, I'd appreciate another pair of eyes. Thanks!
(In reply to comment #20) > Toni, could you look over the API changes I made to see if I'm missing anything > you might need? I'd like to get at least the API changes in for M6, but since > Chris is away this week, I'd appreciate another pair of eyes. Thanks! I am bascially OK with the API, but how would you separate that from the major changes to implementation and UI? I haven't had much time to look at the details, but anyway here is my feedback: - Some synchronized methods in LanguageManager notify listeners. The listeners should better be called outside the synchronized block. - Why the change from Combo to CCombo? If there is no good reason I'd stick with the native look and feel. - Having different levels of language mappings, it would be good if the inherited mappings were also visible in the downstream levels. It would also make sense to see the default mappings of the built-in content types. - The name of the languages are different than those used in the Project path and symbols page (bug 178033). Thanks!
Created attachment 62387 [details] API changes only; preserves existing behaviour Hi Toni, Thanks for your feedback. I'm posting a new patch that contains the changes to the API but preserves the existing behaviour. The new API methods currently do nothing so we can fill them in after M6. In the meantime, I've been testing the patch I posted yesterday all this week and haven't found any major issues. It hasn't caused any test cases to fail and I haven't seen any significant difference in performance. If you don't have time to look at it before M6, I think I can get some people at IBM to look it over. > - Some synchronized methods in LanguageManager notify listeners. The listeners > should better be called outside the synchronized block. Good point. I'll change this and post an updated patch later today. > - Why the change from Combo to CCombo? If there is no good reason I'd stick > with the native look and feel. I thought there were some usability consistency issues between Windows and Linux if I used Combo instead of CCombo. I tested it out again and found this wasn't the case so I'll preserve using Combo in the updated patch. > - Having different levels of language mappings, it would be good if the > inherited mappings were also visible in the downstream levels. It would also > make sense to see the default mappings of the built-in content types. Good idea. I'll include that information as part of the UI so the user knows what got inherited from where. I might not be able to get this change done for M6, but definitely soon afterwards. > - The name of the languages are different than those used in the Project path > and symbols page (bug 178033). I'll check with the folks from Intel about this. I noticed the bug was marked resolved but I guess it's not yet fixed. Thanks again!
Created attachment 62390 [details] Updated: Remaining changes for language extensibility support This patch incorporates Toni's feedback from comment 21: * Reverted to using Combo * Listeners are now being notified outside of synchronized blocks
(In reply to comment #22) > Created an attachment (id=62387) [details] > API changes only; preserves existing behaviour I am OK to apply these API changes. May I replace the TreeMap with a org.eclipse.core.runtime.ListenerList as container for the listeners in LanguageManager? It is thread safe and more appropriate for that purpose.
(In reply to comment #24) > May I replace the TreeMap with a org.eclipse.core.runtime.ListenerList as > container for the listeners in LanguageManager? > It is thread safe and more appropriate for that purpose. > Yes, please do. I wasn't aware that class existed. Thanks!
(In reply to comment #25) > Yes, please do. I wasn't aware that class existed. Thanks! Done. Moved target milestone to RC0.
(In reply to comment #26) > Done. Moved target milestone to RC0. Thanks very much, Toni!
Created attachment 62806 [details] Updated patch This patch incorporates Toni's feedback about informing the user where languages are inherited from. It also includes implementation for file- and workspace-level mappings including UI for manipulating them via preference/property pages.
Created attachment 63085 [details] Updated patch Resynced with HEAD. This patch also adds test cases.
(In reply to comment #29) > Created an attachment (id=63085) > Updated patch > Resynced with HEAD. This patch also adds test cases. Applied to HEAD. I made a few changes to the test cases. 1) Put them in a suite and added this to the automated integration suite so that they are run in the automated build 2) Made the test class extend from BaseTestCase in case later we have failing tests we want to flag, etc.
We are currently working on allowing the project wide and file specific settings to be set differently depending on which build configuration you have selected. The relevant UIs will get a dropdown at the top which allows you to select the configuration the mappings apply to. Default will be "All configurations".
Created attachment 65140 [details] New patch: Adds support for build configuration-based language mappings This patch adds support for build configuration-based language mappings. The relevant API in ProjectLanguageConfiguration and LanguageManager now accept ICConfiguration as an optional parameter when setting/getting language mappings.
Applied to HEAD. Thanks Jay. There is a problem with the C99 and UPC ILanguages that prevents them from being properly added to config level prefs. We'll fix that separately.
