Too many open Editors - can't read name #1570
Comments
|
eclipse.buildId=4.31.0.I20240124-1800 |
|
fyi: maybe #1071 is the reason, as also reported in #1071 (comment) |
|
i also get a lot of exceptions in the log while doing it:
|
@marcushoepfner @praveen-skp please check |
|
I hope the Platform's SimRel m2 will not be like this! |
|
the BadLocationException seems unrelated, i also can reproduce it in 2023-12 |
😱 |
I also get this regulay together with:
it makes working with Java quite hard, sometimes its all wrecked and I need to restart my IDE to even get save working in the Java editor again... |
|
@jukzi are you able to reproduce the behavior of editor tab titles reduced to one character in an Eclipse application started from within an Eclipse IDE? I always have the old, proper behavior there and only face the changed behavior in my "main" Eclipse IDE. Both are based on the current state, i.e., an Eclipse application is started from up-to-date sources and TP, and main Eclipse IDE uses artifacts from Wednesday's I-Build. |
|
Small addition: it seems like somehow no editor area is present in our IDEs (anymore). You can see that when you have no document open (e.g. in the Java perspective), the onboarding information is not shown: Since the documents are opened in a view area (which always had a minimum character size of 1 for the tabs), the behavior seems to be "correct", except that there should be an editor area. |
|
Looks like some configuration for the workbench window (e.g. in the
Luckily, this does not seem to be the case. |
no. i only see the defect in the binary. |
The question is then what broke it and what will happen if anybody updates it's IDE with M2... will it break their workspace too? It's not enough to find a workaround to fix it if the workaround will be needed by almost everyone |
Sure, but I am not able to do that anymore as I lost my faulty state by finding the "workaround". And all my other IDEs setups seem to be fine. Can you please share your workbench.xmi of the broken IDE? Maybe we can find something in there. |
|
I think this got into this state just Oomphing the SDK setup from scratch on January 20th. I rename the file extension to be able to drop it: |
|
I can confirm that unzipping an SDK from the most recent I-Build with a fresh workspace does not manifest the problem. |
|
A freshly Oomphed SDK also does not manifest the problem. |
|
Thank you both for provinding the workbench.xmi and thanks for confirming that new setups do not have that problem, Ed! I have tried with your workbench.xmis and they reproduce the problem, so it is manifested somewhere in that xmi. I have tried to reduce it to a simple version and compare it with a properly working one, but did not find yet what property causes the problem. Maybe I can spend some further time to find it this afternoon. |
|
@HeikoKlare you probably want to look for the |
Thank you, @laeubi! That was a great help. Usual workbench.xmis contain an entry like this for the shared area: <sharedElements xsi:type="advanced:Area" xmi:id="_bHmz0LxDEe6VlZTMrUoCsQ" elementId="org.eclipse.ui.editorss">
<children xsi:type="basic:PartStack" xmi:id="_bHmz0bxDEe6VlZTMrUoCsQ" elementId="org.eclipse.e4.primaryDataStack">
<tags>org.eclipse.e4.primaryDataStack</tags>
<tags>EditorStack</tags>
</children>
</sharedElements>Such an entry is missing in the "broken" xmis, or, more precisely, the according area entry contains a reference to a part stack whose id does not exist in the xmi, like: <sharedElements xsi:type="advanced:Area" xmi:id="_ESRH0LE_Ee6CSp5WgbUKJA" elementId="org.eclipse.ui.editorss" selectedElement="_AMAdMLuMEe6h0tprd-b7rg">
<children xsi:type="basic:PartStack" xmi:id="_AMAdMLuMEe6h0tprd-b7rg" elementId="PartStack@23ad2d17"/>
</sharedElements>Replacing this entry with the upper one fixes the issue. But I have to admit that I still have no real clue why some update broke the configuration. I have taken a look at recent changes to code related to the shared area, but the only ones I found are #1461 and #1462 and I do not see any reason why they should produce this behavior. |
|
@HeikoKlare I now encountered the same problem, I tried to use "Reset Perspective" but this seem not to help. Regardless of editor area or not I find it a bit uncomfortable to have things shrink that small at all, this does not seems useful at all it even goes to the extreme that only the closing [x] is shown for a tab meaning I can not select a tab at all but only close it unless I'm very very careful finding the last pixels that not belong to the close button:
|
|
Use Window -> New Window. Close the old Window. I think key shortcuts don't work in new window, so then a restart and all should be better. |
|
is it possible that the workbench.xmi error exits for a longer period, but only became apparent due to the narrower representation? |
I don't think so. There is no narrower representation at all. This has always been the behavior for part stacks, except for the one of the shared area. |
@HeikoKlare any hint to the sourcecode where those |
|
@merks @HeikoKlare : Can you pls. have a look at the draft PR #1712. |
|
For completeness, this is a copy of the content in the above PR describing how to reproduce the problem: When trying to reproduce the cause of the problem I already notice this problem, i.e., if you drag an editor to create a split editor area, the second area's tabs are squished:
If you now close all the editors and open new editors, those tabs are squished as well:
So it's highly likely that anyone who ever create such a split editor area will always see this problem and will them permanently see this problem... |
|
I have the impression that the issue with the disappearing tag already exists longer (did somebody test with the previous release?) and that the changes to the tab rendering "only" make it visible. Do you agree? |
|
Yes, I have the impression this has existed for a long time and is only obvious now because of rendering that 100% relies on the tag. In general it's not even clear if more than one area should have the tag, what else is the purpose of the tag, what else doesn't work when the tag is missing, and so on... |
|
Thanks, Ed! That actually seems to be the root cause of the problem. It is even reproducible with older Eclipse releases. I tested with Eclipse 2023-06 and the same behavior (editor area being lost) occurs. It does not have the effect of small tab headers in that release, but you can see the onboarding area disappearing (which was introduced with 2023-06 IIRC) and of course by looking at the workbench.xmi. After starting new IDE: After splitting editor area and closing the remaining tabs of the original editor area: It does not make sense to try to fix the root cause for 2024-03 since it would be too risk to merge anyway, right? So for now focussing on fixing the tab headers (like addressed in #1712) is sufficient? |
|
We don’t know the risks without knowing what needs to change. But the change for the rendering logic is only that some tabs might not be so squishy which is way less horrible than unreadable editor tabs. |
Sure. I can have a look at how to fix the root cause, but unfortunately I am quite busy the next days, so if anyone wants to work on that meanwhile, feel free. The problem seems to be that a part stack is removed once the last part in that stack is closed. This is the case even if the editor is a shared/editor area. My expectation would be that the shared editor, when activated, can never be closed. So in the problematic scenario (splitting the editor area and closing the last tab in the original area), I see options:
The second option could look as follows. When starting with this: ... I would expect this: ... while currently it is this: If anyone knows where the according code that removes a part stack once the last part is closed is located, it might be an easy fix. |
I just updated the PR with @merks proposal. |
Maybe @vogella knows this. |
|
Here are some further insights, which I want to share for those interested in the information or interested in working on the bug, as I will not proceed with this for the next days. Current BehaviorWhenever you split the shared area, so that it contains multiple part stacks, and then close the last editor in the original part stack (which is the "primaryDataStack"), the "primaryDataStack" will be lost. The code that removes a part stack is this, precisely the call When you close the last editor in the primary data stack, that part stack will simply be removed. Then no part stack being the primary and potentially also no part stack being tagged as Interestingly, the part stacks with element id Expected BehaviorI would expect the following behavior:
The creation of a new part stack by splitting an area via drag & drop is handled in You can see that this new part stack will never be tagged as "EditorStack". When such a part stack becomes the last remaining in the shared area, without any editor open, the onboarding information is not shown as this depends on presence of exactly that tag: Preliminary SolutionWith the following adaptation of private void synchCTFState(MArea areaModel) {
final String primaryDataStackId = "org.eclipse.e4.primaryDataStack"; //$NON-NLS-1$
List<MPartStack> stacks = findDirectStacks(areaModel);
List<MPartStack> visibleStacks = new ArrayList<>();
boolean removingPrimaryDataStack = false;
for (MPartStack stack : stacks) {
if (stack.isToBeRendered()) {
visibleStacks.add(stack);
} else {
if (primaryDataStackId.equals(stack.getElementId())) {
removingPrimaryDataStack = true;
}
}
}
if (removingPrimaryDataStack && !visibleStacks.isEmpty()) {
MPartStack newEditorStack = visibleStacks.get(0);
newEditorStack.setElementId(primaryDataStackId);
newEditorStack.getTags().add(primaryDataStackId);
newEditorStack.getTags().add("EditorStack"); //$NON-NLS-1$
}
// If there's more than one stack visible we use a CTF
if (visibleStacks.size() > 1)
ensureCTF(areaModel, stacks);
else {
ensureComposite(areaModel, stacks);
}
} |
CleanupAddon should be responsible for this. If you add a tag from the IPresentationEngine to the stack it is ignored,the tag is called IPresentationEngine.NO_AUTO_COLLAPSE |
|
We have preliminary fix for this. Does anybody plan to provide PR for the "final" fix? |
|
My sense is that this is the correct fix for the problem (as described by the title) because it works when there are multiple areas. It's not clear if multiple tagged areas should be created when there are multiple editor areas. In any case, it is still a bug that the tag disappears so that we don't see the helpful "empty editor area" content:
I think it would be best to open a new separate issue for that specific problem;it can be linked this issue which we could revisit when that other issue is fixed. |
I've started to work on a "final" fix but did not find the time to finalize it yet.
That makes sense. I can create that issue and open a draft PR to share my preliminary experiments, hopefully by the end of the week. |
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtils, which currently contain functionality related to the primary data stack, which also relies on the being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (eclipse-platform#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (eclipse-platform#1775, eclipse-platform#1778). Contributes to eclipse-platform#1570 Contributes to eclipse-platform#1773
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtil, which currently contain functionality related to the primary data stack, which also relies on the being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (eclipse-platform#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (eclipse-platform#1775, eclipse-platform#1778). Contributes to eclipse-platform#1570 Contributes to eclipse-platform#1773
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtil. This utility class currently contains functionality related to the primary data stack, which also relies on being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (eclipse-platform#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (eclipse-platform#1775, eclipse-platform#1778). Contributes to eclipse-platform#1570 Contributes to eclipse-platform#1773
I have created #1806 with some final cleanup after having introduced proper handling of the primary data stack and editor stacks in recent PRs (#1775, #1778). It also reverts the preliminary fix for this issue, which was only applied to avoid the bug to be visible in the 2024-03 release and which was introduced with #1712. |
|
So when there are multiple editor areas, none of those areas will have the shrunken tabs issue, but only one is marked as the primary stack? |
|
Exactly, this is how a split-up shared area looks after this PR. Note that there are more than the displayed tabs in both stacks, but the visible ones have proper name lengths.
|
|
Awesome. 💯 |
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtil. This utility class currently contains functionality related to the primary data stack, which also relies on being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (eclipse-platform#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (eclipse-platform#1775, eclipse-platform#1778). Contributes to eclipse-platform#1570 Contributes to eclipse-platform#1773
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtil. This utility class currently contains functionality related to the primary data stack, which also relies on being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (eclipse-platform#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (eclipse-platform#1775, eclipse-platform#1778). Contributes to eclipse-platform#1570 Contributes to eclipse-platform#1773
The functionality for creating and identifying editor stacks based on the "EditorStack" tag is scattered across several code places. This change centralizes the according functionality in the recently introduced PartStackUtil. This utility class currently contains functionality related to the primary data stack, which also relies on being an editor stack. In addition, this change reverts the preliminary fix for visible names of open editors being to short (#1712) as this became obsolete with the recent improvements of handling primary data stacks and editor stacks (#1775, #1778). Contributes to #1570 Contributes to #1773
open all files in org.eclipse.jdt.internal.compiler.ast
this is how it used to look:
this is how it looks now:
The text was updated successfully, but these errors were encountered: