Community
Participate
Working Groups
Folks, Eclipse-3.x provides an IContentManager and extension points to identify a type, great. But for the a C/C++ environment where filenames are more dynamic say; "cstdio", "iostream", it is not possible to define __all__ filenames in /usr/include and also users can change things; adding new files. CDT provides a way to deal with this, but we can not hook up to the IContentType stuff since when the IContentDescriber is call we do not get the filename but only the inputstream.
The content type definition is intended to be the place where the associated file specs are defined. Content describers do content type identification based on contents only. If one submits an input stream *and* a file name to the content type manager, only content describers for content types associated to that file name will be queried. If you need extensibility for file specs (you want to allow the user to add new file specs), there is API for that: IContentType.add/removeFileSpec. That being said, I am not sure I understood what is your scenario. Please clarify: - what do you want use content types for? - what content types are you planning to provide? - what would be the behavior for the corresponding content describers?
> That being said, I am not sure I understood what is your scenario. Please > > clarify: C/C++ environment is more dynamic, what's define to b a C/C++ file is not set in stone. And it may depend on the compiler, the platform or the user customizations. For example when using Cygwin *.tcc should be consider C++ files, a user may define that "map" is the name of the header and should be consider like a C file. > - what do you want use content types for? The content types is use to find the right sourceviewer for example when doing comparison. You can add to the extension of the "Comparator" or the strutureviewer for whihc content type it applies too. Unfortunately, I do not think the Editor extensions provide this yet ... another PR 8-) > - what content types are you planning to provide? I want to define a C_source content type and C++_source content type. When giving the filename, I can quickly search in my internal database if the filename is a valid name for this environment. > - what would be the behavior for the corresponding content describers? The C/C++ describers will say yes/no if it recognise this filename as a valid C/C++ filename. A recognition is not base on the inputstream but rather on the filename pattern. > If you need extensibility for file specs (you > want to allow the user to add new file specs), there is API for that: > IContentType.add/removeFileSpec. Now I'm not sure I understand your meaning here 8-(
What I meant is: file name-based association to content types is done in the extension markup in the plug-in manifest. For instance: <extension point="org.eclipse.core.runtime.contentTypes"> <content-type id="cSource" name="%CSourceContentTypeName" base-type="text" file-extensions="c"/> <content-type id="cHeader" name="%CHeaderContentTypeName" base-type="text" file-extensions="h"/> </extension> Declares two text-based content types with no content describers. You don't need to provide a content describer because you don't care about contents. Check out the definition of Java source files in org.eclipse.jdt.core's manifest. As you pointed out, the user may want to associate a content type to other file names. For instance, if the user wants to have its files called myProgram.xyz and *.ccc associated with the C_Source content type, you can do: IContentTypeManager manager = ...; IContentType cSource = manager.getContentType("org.eclipse.cdt.core.cSource"); cSource.addFileSpec("myProgram.xyz", IContentType.FILE_NAME_SPEC); cSource.addFileSpec("ccc", IContentType.FILE_EXT_SPEC); From that moment on, the cSource content type will be associated with myProgram.xyz (set by user), *.c (set by plug-in provider) and *.ccc (set by user). So, instead of you doing the name matching, it is done for free by the content type manager. About file editors not using the content type mechanism, don't bother opening a PR for that: check bug 37668. It is going to be addressed for 3.1. I am going to close this one since what you require is already supported. Reopen later if you disagree.
> IContentTypeManager manager = ...; > IContentType cSource = > manager.getContentType("org.eclipse.cdt.core.cSource"); > cSource.addFileSpec("myProgram.xyz", IContentType.FILE_NAME_SPEC); > cSource.addFileSpec("ccc", IContentType.FILE_EXT_SPEC); ... > I am going to close this one since what you require is already supported. > Reopen later if you disagree. I disagree, this does not work as advertised. If you do : IContentType.addFileSpec("myTxt", IContentType.FILE_NAME_SPEC); Then later IContentTypeManager.findContentTypeFor("myTxt"); It does not work. The ContentTypeManager maintains maps of the fileExtensions and the fileNames adding new specs will not change those mappings. So adding new spec via IContentType.addFileSpec() has no effect. Whether the ContentTypeManager get rid of those maps and iterate through the contentType or every time you add a spec the ContentTypeManager gets notification to update its mappings. Looking carefully at the internal class ContentType You will see adding file specs the ContentTypeManager, is not
Original summary: "IContentDescriber does not provide the filename" Ouch. I missed this important use case in the tests. The other relevant use case (which was tested and works) was for when the client has a content type in his hand and wants to know if a given file is associated with it (for instance, a builder traversing the workspace, looking for files to process). Alain, are you shipping on top of 3.0.1 or 3.1? Do you have any workaround (I can't think of any)?
> Alain, are you shipping on top of 3.0.1 or 3.1? It will be for 3.1, wich will probably match to the release of CDT-2.1. A little of history, CDT has a resolver Model, basically doing the same thing that IContentManager is doing, but when Sam Robb wrote that code, IContentManager did not exist. The CDT resolver Model offers : - content type resolving via extension (same technique as the IContentManager) - resolving per project or the global/workspace This is all good with a __big__ problem, interoperability between CDT Resolver Model and Eclipse is null. So although you designate *.pc to be a C++ File, the Editor will not be the right one, the diff/comparator will not choose the right sourceViewer etc ... So the idea for now is to provide a bridge and phasing out the CDT Resolver. But we would need: - the IContentManager to work as advertised(This PR covers this) - provide per Project contentType overriding the global default. For example, a QT Project will *.pc as a C++ file, but this association should not hold globally, I think I have a Pr covering this. > Do you have any workaround (I can't think of any)? Nope, no workaround, nothing that the CDT can fix the problem. For example when the StructureCreator(diff view) is looking for content type for the files, it calls IContentManager.findContentTypeFor(..) which will return .. null.
Ok, I will try to fix this (for 3.1) at the first opportunity I have. Please bear with us... CDT will likely be the first client for this API (IContentType.add/removeFileSpec).
> Ok, I will try to fix this (for 3.1) at the first opportunity I have. Please > bear with us... CDT will likely be the first client for this API > (IContentType.add/removeFileSpec We will be more then happy to assist; code/testing/patch etc .. Just say what you need 8-) We can not found a workaround for 3.0.1, because the problem is not in CDT. Our problem is inter-operability, all other modules in Eclipse use IContentManager.findDescriptorFor(..) to discovery the contentType For example the StructureViewer, team plugin etc ... So I do not how to tell those module, hey! the CDT just added a new FileSpec ... Anyway Thanks Rafael.
Was there any action on this PR in the head ? This is crucial for us(CDT). We would like to make this a reality asap.
Alain, please use the severity field to state how important a bug is for you. The priority is used for planning purposes and should be changed by the bug owner only (I know, I know, Bugzilla should prevent you from doing that in the first place). I plan to attack the content type manager rework as the first thing after M4 (two weeks from now). Is it too late for you?
> Alain, please use the severity field to state how important a bug is for you. Noted. > I plan to attack the content type manager rework as the first thing after M4 > (two weeks from now). Is it too late for you? Thanks. We can wait, we just to get this asap, lots of PR depends on this and we have to move the entire CDT to use this scheme, it affects everyThing.
> I plan to attack the content type manager rework as the first thing after M4 > (two weeks from now). Is it too late for you? This getting more pressing everyday. This is a real big issue for not, since the CEditor is using "*" on the extension of the DocumentSetup attribute etc .. We have to use start because we can not use file extensions i.e. iostream, map, etc .. It does not sit well with other plugins. But taking the "*" out cripple the CEditor for files with no extensions.
Alain, it might be seen as too late for plugins other than the CDT (WTP) that want to coexist with the CDT.
> Alain, it might be seen as too late for plugins other than the CDT (WTP) that > want to coexist with the CDT. sigh .. yes stuck between a rock and a hard place... I guess the temporary solution is for the user to remove the "*" and change to "cpp,hh" etc... and accept that files like "iostream, fstream, ..." will not be seen correctly ... According to Raphael the solution will be availabe in 31M5 .... 'til then I'm open to any other workaround.
Fixed. Released to HEAD.
Thanks, seems to work good
