Community
Participate
Working Groups
The choice of editor is currently based on file name patterns. This is not very flexible, and breaks down when fundamentally different types of content are found in files with undistinguished file names or internal formats. For example, many different models with specialized editors get stored in XML format files named *.xml. Eclipse should provide infrastructure support for a notion of content type for files and resources. (This plan item was split off from 3.0 plan item bug 37668.)
A content type registry is in place. Since it was done too late, adoption (in the Eclipse SDK) will be limited, editor-file associations and a central UI for for manipulating content types being the most noticeable missed use cases. Here are the scenarios taking advantage of the content type registry: - non-uniform file encoding in the workspace (bug 37933 - [plan item] Improve file encoding support) - file associations in Compare extension points (bug 51791 - Allow binding filenames to compare extensions) - content sensitive object contributions, being retrofitted to work with the content type registry (bug 33018 - [Contributions] plugin.xml context menu should not have "Run Ant..." item) Also, the Team team is considering adopting it as well, not sure about the exact scenario/planned schedule.
Fixed.
*** Bug 52784 has been marked as a duplicate of this bug. ***