Other text editor responsibilities

The Java example editor inherits a lot of useful default behavior from AbstractTextEditor.  The text editing framework handles several other responsibilities that you can customize by overriding methods in AbstractTextEditor.  Browse the implementation of this class and its subclasses to see how behavior is customized in the framework.

The following are some of the useful framework features that can be configured.

Preference handling

Text editors typically contribute user preferences that control the presentation and behavior of the editor.  In the text framework, each text editor instance has an associated preference store that is used for accessing user preferences.  This preference store can be set up by your editor, or you can inherit from preference stores already used in the framework.

In the case of the Java example editor, it inherits the preference store initialized by TextEditor.  This is the preference store defined by the workbench editors plug-in.  

protected void initializeEditor() {
	...
	setPreferenceStore(EditorsPlugin.getDefault().getPreferenceStore());
}

General > Editors

General > Editors > Text Editors

If you do not want to use the standard workbench text preferences for your editor, you can set a different preference store.  This is typically done by overriding initializeEditor and setting your own preference store.  If you do use your own preference store, you will also need to override the method handlePreferenceStoreChanged() which is triggered whenever a preference is updated.

Key bindings

Key binding contexts are useful for establishing a lookup order for key bindings. Having contextual key bindings reduces the chances of different plug-ins contributing conflicting key sequences. By default, the workbench operates in a generic context for working with windows or dialogs. When a text editor becomes active, it is responsible for resetting the context to the text editing context, so that editor specific key bindings will be active.

In the platform text framework, each text editor instance has an associated array of key binding scopes. It is responsible for setting the correct scopes when it becomes active. AbstractDecoratedTextEditor defines this scope and takes care of making it active. The scope is assigned in a method that is called from the constructor:

protected void initializeKeyBindingScopes() {
	setKeyBindingScopes(new String[] { "org.eclipse.ui.textEditorScope" });  
}

The argument to the method is an array of ids that have been defined for contexts. If you want your editor to define its own key binding context, then you can override this method in your editor class, or set the scope dynamically using setKeybindingScopes.

The context itself must be defined with the corresponding id in the org.eclipse.ui.contexts extension point. The following is the definition for the text editing context.

<extension
	point="org.eclipse.ui.contexts">
	<context
		name="%context.editingText.name"
		description="%context.editingText.description"
		id="org.eclipse.ui.textEditorScope"
		parentId="org.eclipse.ui.contexts.window">
	</context>
	...

(Note:  We use the terms scope and context interchangeably in this discussion. The method names in the text classes still refer to key binding contexts as scopes. These method names reflect the original implementation of contexts as scopes and use outdated terminology.)