Project: JDT
Bug 62429 Document partitioner not set when user assigns extension to editor
Reported: 2004-05-16 19:56:37 | Status: resolved fixed

An editor is entitled to assume that its document partitioner will be set. But when the user associates an extension, e.g., "*.foo", with an editor using preferences, the partitioner for the editor is never set and there is no API (plugin.xml or otherwise) to make it happen. This is fundamentally broken in Eclipse and must be fixed before 3.0 ships. Prior to 3.0, an editor could solve the problem by always forcing its own IDocumentProvider when the editor class was initialized. The documentprovider then attached the partitioner to the document when it was created. This was a well-known idiom, used by many editors and in the editor sample code. However, in 3.0, there is a new philosophy: that the documentprovider is chosen by Eclipse, with hooks provided, e.g., IDocumentSetupParticipant, that allow a plugin to get its partitioner established without needing to override the system-provided IDocumentProvider. However, this scheme has the same flaw that previous releases have shared, it is driven by file extension and therefore doesn't work when the user just makes up a new extension for, e.g., Java or XML files. This puts an editor plugin in an awkward position. If it forces a particular documentprovider, the editor won't work with the new TextFileDocumentProvider and therefore won't work with Open External File. If it doesn't, it won't work correctly with user-invented file extensions.

Files changed in fix:
org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/javaeditor/CompilationUnitDocumentProvider.java