Community
Participate
Working Groups
In 1.0m3, I have a set of editor associated to various file extensions. The file format is xml, so I had previously done an: <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.core.runtime.xml" file-extensions="..."/> </extension> to get Eclipse to pull the file encoding from the xml decl. This worked fine in that my editors were the defaults for the files, but the xml editors were available in the Open With... menu. After switching to 1.0m4, my files are associated with the XML Source Page by default. I switched my editors to have default="true" in plugin.xml, but that didn't help. In the General|Editor|File Associations preferences page, my files do show their appropriate editors being the default. In General|Editor|Content Types, they show up as (locked) under XML. They open with the XML Source Page editor by default. I would think the contentType based associations should not override an editor set to default="true", unless the user chooses to do that. As a workaround, I'm going to not associate my files with the xml contentType, but make my own that does the same thing. However, with this, the xml editors don't show up in the Open With... menu anymore.
Greg, can you clarify ... you have another editor you want to use for your own file type, which is xmlish, but which has an extension other than *.xml .. right? (I can't imagine hy anyone would not want to use our editor, but I have heard of such cases :) And your editor is only for that one file extension, not xml in general, right? While there's probably more investigation needed here, and there are changes to the filetype/contentType "ordering" in M7 (our WTP M5) which may effect this, I'm wondering if one thing you could help investigate is if associating your editor via the contentType association would help (instead of the filetype association). In principle, you could define your own "subtype" of xml and have the editor just associated to that. While we may want to test better and make recommendations the base handle 'default' in a more compatible way, I'm wondering if you've investigated this approach (and if it would be one avenue of a work around, if none other were found). Hopefully these suggestions will help you make clearer to me exactly what's going on here and what our next steps should be. (BTW, there's several other bugs/featues requests on improvemtents in meaning of 'default' for editor management] BTW, one thing to be sure to check, after you change the plugin(s) to have different 'default' settings, you might have to restart with -clean to get them "noticied" and refreshed. Thanks, For example, our editor-to-contentType association is defined this way. <extension point="org.eclipse.ui.editors"> <editor name="%XML_Source_Page_Editor.name" icon="icons/sourceEditor.gif" default="true" contributorClass="org.eclipse.wst.xml.ui.internal.actions.ActionContributorXML" class="org.eclipse.wst.xml.ui.internal.provisional.StructuredTextEditorXML" symbolicFontName="org.eclipse.wst.sse.ui.textfont" id="org.eclipse.core.runtime.xml.source"> <contentTypeBinding contentTypeId="org.eclipse.core.runtime.xml" /> </editor>
David - Your assumptions are correct. I have a visual, drag-n-drop, point-n-click type editor for files which are xml format but have a different file extension (let's say '.cam'). This editor is just for files of this extension (which match a certain schema that this editor is hard-coded to know about). I want my editor to open by default for .cam files; it would be nice if the XML Editor was available in the Open With... menu and/or via the user changing their Content Type and/or File Association preferences. I wasn't aware of the contentTypeBinding in M6. I tried out your suggestion of making a new contentType (with base type of xml) and associating my file extensions to that. Seems to work like a champ. My editor opens by default, and XML Editor/XML Source Page Editor are automatically in the Open With... menu, and it's getting the IResource correctly encoding via the xml decl. So, I think I'm set for this. Thanks for the heads up. However, I still think the current editor-choosing behavior is incorrect and should be rectified. It's a bit confusing to have both Content Type and File Association settings for specifying editors for files, especially since there's no information visible to the user about which one wins. Also, if there are already built editor plugins in this same situation (esp. ones not tested in conjunction with wtp), they will have this same problem and will stop being the default editor when used in an eclipse w/ WTP also in it. My view on it is that the most-specific should win in the case of a tie. So, there's 2 ways to automatically associate editors: via a filename/extension association, and via a contentTypeBinding. To me, the filename/extension association seems more specific. So, if there's a filename and contentTypeBinding both with default="true", I would think the filename/ext should win. Of course, that's just my $0.02 on the matter. Now that I've got a fix for my exact problem, I'm willing to let others more involved make the decision. If the other bugs/feature requests on editor managment cover this issue, feel free to resolve this to WONTFIX. Otherwise, can you get this bug in with the rest for consideration? Thanks.
*** This bug has been marked as a duplicate of 95317 ***
Changed Version field given new release numbering.
Sounds good.
