Bug 110602 - [EditorMgmt] Expose EditorRegistry, FileEditorMapping as API
Summary: [EditorMgmt] Expose EditorRegistry, FileEditorMapping as API
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: api, helpwanted
Depends on:
Blocks:
 
Reported: 2005-09-26 10:51 EDT by Ankit Pasricha CLA
Modified: 2016-04-14 06:25 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ankit Pasricha CLA 2005-09-26 10:51:55 EDT
Currently, IEditorRegistry and IFileEditorMapping interfaces do not expose all
the functionality that is required for adding new file types to eclipse
programmatically. The implementation classes are needed in most situations where
file type mapping changes has to be made.
For instance, EditorRegistry.setFileEditorMapping() method is not exposed by the
IEditorRegistry interface. Also, this method takes FileEditorMapping[] array
which is not exposed.

Eclipse should expose the EditorRegistry.setFileEditorMapping() method as an API
and also make FileEditorMapping class external.
Comment 1 Ankit Pasricha CLA 2005-09-26 11:02:52 EDT
Another important method in EditorRegistry is the saveAssociations() which
should be exposed to serialize the changes made to the FileEditorMappings
Comment 2 Kim Horne CLA 2005-09-27 09:19:59 EDT
Doug, I'm poking around in here now but doing this was not part of my plans...
Comment 3 Ankit Pasricha CLA 2006-01-13 14:21:03 EST
I was wondering if this would be fixed as part of 3.2? I would like to avoid using internal APIs completely and there doesnt seem to be another way of modifying file types.
Comment 4 Robert M. Fuhrer CLA 2006-04-11 14:17:45 EDT
What's the status of this? I'd also definitely like to see this become API. Our project for language-specific IDE support (SAFARI) uses a single editor to service several languages, with various services contributed via extensions to SAFARI extension points.

I only see two ways of implementing this: (1) pretend that our editor is the default editor by using the ID org.eclipse.ui.DefaultTextEditor (this is obviously bad), or (2) have it register itself as the default editor for each file-name extension that it finds in the contributed SAFARI plugin extensions (much more desirable, this is what we do now).

The latter solution requires everything that was mentioned in the original post.

Also, many/all of FileEditorMapping's methods (e.g. setDefaultEditor()) talk in terms of EditorDescriptor rather than IEditorDescriptor, but none of their implementations seem to need an EditorDescriptor in particular. So, I think all the various method signatures should be changed to use IEditorDescriptor.
Comment 5 Kim Horne CLA 2006-04-11 14:18:56 EDT
This will not be addressed for 3.2 but there is talk of revisiting the editor API in the next release.
Comment 6 Susan McCourt CLA 2009-07-09 19:08:10 EDT
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Comment 7 Boris Bokowski CLA 2009-11-17 13:00:32 EST
Remy is now responsible for watching the [EditorMgmt] component area.
Comment 8 jumpingstone CLA 2011-08-01 23:26:44 EDT
my project also need such functionality that dynamically change the default editor according to the perspective. is there any update ? I don't think this two APIs is exposed in indigo release.