Multiple tab labels for diff editors #116178
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #110694
Diff editors can have a tab label that is too long in some cases. This PR implements the ability for tabs to have multiple labels, each with separate code icons and shortened paths, and makes use of that for diff editors.
The alternative to this would be to just shorten the paths but keeping the current way of labeling. I have implemented that as well. See #110694 and master...goldst:shorten-diff-title-A for details.
Test this by opening two files with the same name but different paths, then ctrl+shift+p -> compare active file with...
Overview of the most important changes from a technical point of view:
getNamesandgetDescriptionstoIEditorInputso editors can have one or multiple labels. Implement these inEditorInputwhere they return the name and description, and override them inDiffEditorInputto return all three labels (left editor, compare arrow, right editor)tabTitleControl.tsgets all names and descriptions and shortens paths even when there are multiple paths in one labellabel.ts(egMultipleResourceLabelsandResourceLabelWidgets) that have mostly the same methods as the ones previously in use, but they are a wrapper for multiple objects of the previous classes. Also added some interfaces/parent classes (egIResourceLabels,IResourceLabelWidgetandResourceLabelGroupBase) to make sure they behave in the same way as the ones used previously.This PR might have some implications that weren't clear to me, that's why I suggest that it should be reviewed thoroughly. I would also like to have a general yes or no for this approach before I/we fix the merge conflicts.