Replies: 1 comment 2 replies
-
I've not looked detail, but I expect it should be using So I think "we" should find a way to fix this properly in the framework. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
In our application we have multiple types of editors for the same file. An example would be we have an Xtext DSL editor for an EMF model, and we also have an editor that is a MultiPageEditor which contains NatTable visualizations of the EMF model on its various pages.
The underlying IEditorInputs for both of these editors are FileEditorInputs, and because they are editing same file, Eclipse considers these FileEditorInputs to be equal. This has caused problems that we have noticed in regards to the back/forwards navigation in our application.
In particular, we noticed that NavigationHistoryEntries when navigating between these two editors were being merged together, because the FileEditorInputs were considered equal. This prompted the opening of #339 which I then contributed a fix for.
This fix enabled distinct NavigationHistoryEntries to be added to the NavigationHistory when navigating between these two editors, however we have noticed further problems. For example, when switching between editors, the displayed text of NavigationHistoryEntries in the go back/forwards dropdowns (the NavigationHistoryAction class) changes, because in the getHistoryText() method of NavigationHistoryEntry, it replaces the historyText with the result of a call to location.getText(), which calls getEditorPart(), which calls page.findEditor(input). This method calls findEditors and then simply returns the Editor of the first IEditorReference found in findEditors. This all results in the incorrect EditorPart sometimes being found for the NavigationHistoryEntry and thus the display text for the entry is incorrect.
Additionally, when actually selecting one of the NavigationHistoryEntries to go to, often the incorrect editor is opened. This is because in the method restoreLocation() of NavigationHistoryEntry it calls page.openEditor, which even in the Javadoc states that if an already opened Editor for the given EditorInput exists, it brings that to the front instead of opening a different/new Editor (notably, even if the editor IDs are different).
This all boils down to Eclipse seeming to expect that if the IEditorInput of two editors are the same, then those Editors should be treated as instances of the same Editors, which in our case is not true. Thus our problem could be solved by simply implementing our own IEditorInput for these editors with their own equals logic. However, the comments from greg-449 on this stack overflow post seem to imply that overriding getEditorInput() of our editors to provide our own IEditorInput is not the correct solution.
So this leads to my question, what is the correct Eclipse way to define multiple editors that will edit the same file? Is there some way I am not aware of of specifying what kind of IEditorInput Eclipse will pass to an Editor upon class construction? Is there something else entirely that needs to be done for this use case?
Thank you for your time,
Greg Detweiler
Beta Was this translation helpful? Give feedback.
All reactions