I've embedded a textual (Xtext) editor in a graphical (GMF) editor to
allow combined textual/graphical editing. The text editor shows a
section of the textual representation of the same file. It pops up in a
small control if a diagram element is edited and closes on a defined key
sequence.

So the speciality of this case is that an editor is not opened in a
IWorkbenchPage but in a separate control. Most of it works fine, but
some keybinding issues remain:

To instantiate the Xtext editor I need an IEditorSite. I have tried two
options: Reuse the one from the diagram editor or create my own. In the
first case, after closing the popup Xtext editor the keybindings of the
parent diagram editor are lost, e.g. CTRL-S no longer works. Switching
to another part an back keybindings are restored. In the second case,
the Xtext specific keybindings are not activated in the popup editor, so
CTRL-SPACE for code assist does not work. Into the bargain, creating a
new IEditorSite is not possible without using internal API. It is
usually created by the runtime when activating an editor in a workbench
page.

The keybinding problem seems to be a missing context switch when opening
/ closing the XtextEditor. Debugging I found that a command for content
assist is there but has a null handler.

The editor's controls are created as children of the diagram control
using something like
xtextEditor.createPartControl(diagramParentComposite);
After editing, the editor is closed using
xtextEditor.dispose();
xtextEditorComposite.dispose();

Any ideas pointers are welcome. Am I approaching the problem completely
the wrong way?

it comes from trying to next a part within another part. It's just not
supported in 3.x. I don't think you'll be able to do much without
hacking internals. You could look at MultiPageEditorPart (and its inner
sites and inner services).

If you can get that working, though, you'll still have to mediate
between your main editor and your inner editor (there's no way to
disable the main editor keybindings while your inner editor is up, so
they had better just work or you'll have to swap around the context
hierarchy so that there are no conflicts).

Could you nevertheless give me a hint how to switch the context or
enable certain keybindings "manually"? All my efforts so far were not
very fruitful.

I think to have figured out that this usually happens in
BindingManager.recomputeBindings()
which in the default case is called as an effect of a chain of mainly
internal listeners.

Any hints are welcome!

Cheers
Jan

Paul Webster schrieb:
> it comes from trying to next a part within another part. It's just not
> supported in 3.x. I don't think you'll be able to do much without
> hacking internals. You could look at MultiPageEditorPart (and its inner
> sites and inner services).
>
> If you can get that working, though, you'll still have to mediate
> between your main editor and your inner editor (there's no way to
> disable the main editor keybindings while your inner editor is up, so
> they had better just work or you'll have to swap around the context
> hierarchy so that there are no conflicts).
>
> If you make progress we'd love to hear about it.
>
> PW
>
>

Jan Koehnlein wrote:
> Oh, thanks for your answer, even though it's bad news :-(
>
> Could you nevertheless give me a hint how to switch the context or
> enable certain keybindings "manually"? All my efforts so far were not
> very fruitful.
>
> I think to have figured out that this usually happens in
> BindingManager.recomputeBindings()
> which in the default case is called as an effect of a chain of mainly
> internal listeners.
>

It's a change in the contexts that cause the binding manager to
re-compute the bindings.

org.eclipse.ui.part.MultiPageEditorPart.activateSite() deactivates one
inner site and activates the new inner site ... the
NestableContextService would then swap active contexts, which cause the
keybindings to be updated ... if it was done correctly :-)