Community
Participate
Working Groups
Build id: M20090211-1700 Steps to reproduce: 1. Open any text file (or any other file with a simple text editor, too keep it simple) 2. Choose 'Window > New Editor' to get a second editor for the resource 3. Change the contents of one editor and observe how both editors become dirty (asterisk in tab) 4a. Make sure that only one of the two editors is visible at a time (stacked, as by default) 4b. Restart the workbench (no need to save the changes made in the editors) 5. Change the contents of one editor (do not touch the other editor in order not to activate it) Expected result: Again, both editors should become dirty. Actual result: Only the editor where the change text file was changed becomes dirty, the other editor does not change its dirty state. This is inconsistent with the behavior before restarting and non-intuitive for the user. As soon as the second editor is activated, its dirty state will be updated correctly. I assume the second editor was not able to update the dirty state in sync with the first editor simply because it had not been activated yet.
Yes. We do not materialize editors until they are shown, at which point we can tell that the two editors operate on the same file.
Created attachment 127972 [details] Proposed patch Considering that an editor description in the workbench's memento provides enough information to restore the editor, shouldn't it be possible to find all editors which operate on the same input as the one being activated, without restoring all editors? I was curious whether this could be solved without too much effort and gave it a try (attached). Whenever an editor is restored, all editors for the same ID and input are also restored as well. This seems to solve the problem -- but I am not an expert on Platform UI.
Thanks for the patch, will have a look at it for M7. The idea sounds good.
Released to HEAD. Thanks!
Boris, this fix is a no-go, please revert it: it causes all editors with same input as the active one to be materialized on start up and each time another editor is activated, all similar ones are also activated. The costs are to high just to have this little '*' in the tab later (assuming someone is even starting to type in that editor). A correct fix would listen for changes to the dirty property and then update the tab without loading the editor.
(In reply to comment #5) > Boris, this fix is a no-go, please revert it: it causes all editors with same > input as the active one to be materialized on start up and each time another > editor is activated, all similar ones are also activated. Not sure I agree. The editors would have to have the same input and id, and be in the same workbench window. Yes, there is an additional cost of materializing a second copy of the same code, but this is not a very common setup, and when it happens it's potentially confusing.
>Yes, there is an additional cost of materializing >a second copy of the same code, Maybe more. > but this is not a very common setup, and when >it happens it's potentially confusing. So far in 7 years no one reported it and if it is not common, why take that risk one week before RC-mode? Are you sure that the getPart method you changed is not used in any other context/scenario which now also suffers this side effect? What's the problem implementing the * based on the property change? I still like to back out of this change (at least for 3.5).
*** Bug 70363 has been marked as a duplicate of this bug. ***
Created attachment 135166 [details] patch to revert the change (In reply to comment #7) > >Yes, there is an additional cost of materializing > >a second copy of the same code, > Maybe more. Yes - however many editors were open in the last session, with the same editor id and editor input. > > but this is not a very common setup, and when > >it happens it's potentially confusing. > So far in 7 years no one reported it and if it is not common, why take that > risk one week before RC-mode? I did not see this as a particularly risky fix, but agree that there is a potential performance effect. > Are you sure that the getPart method you changed is not used in any other > context/scenario which now also suffers this side effect? Whichever context/scenario we had that materializes the editor, yes, it would cause the same side-effect. We try very hard not to materialize editors until the user clicks on the tab, though. > What's the problem implementing the * based on the property change? I would expect this to be a more complicated and riskier change. But it's certainly doable. > I still like to back out of this change (at least for 3.5). Sure, we can back out of this. Dani, can I get your +1 for this patch?
+1 for https://bugs.eclipse.org/bugs/attachment.cgi?id=135166 for RC1.
attachment 135166 [details] released to HEAD. Moving to 3.6.
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
