-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFE] Add support for "editor" content types for compare editor / contentViewers extension #1747
[RFE] Add support for "editor" content types for compare editor / contentViewers extension #1747
Comments
Extend `contentMergeViewers` extension point: add an attribute to consider "linked" editor content type associations. The code checks if contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypes for the contentMergeViewers. Updated CompareViewerSwitchingPane to consider more precise title calculations for ContentMergeViewer instances (where concrete type info is available after instantiation of a particular viewer). Fixes eclipse-platform/eclipse.platform.ui#1747
This allows GenericEditorMergeViewer be used by compare editor for content types associated with the generic editor. Additionally implemented getTitle() to provide more specific compare editor description, so instead of default "Text Compare" one would see "XML Compare" etc. This avoids the problem of duplicated "Text Compare" options shown for different compare viewers (default one for plain text and the one for generic editor). See eclipse-platform#1747 See eclipse-platform/eclipse.platform#1277
See
|
@mickaelistria : would be nice if you could review the proposals. |
Extend `contentMergeViewers` extension point: add an attribute to consider "linked" editor content type associations. The code checks if contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypes for the contentMergeViewers. Updated CompareViewerSwitchingPane to consider more precise title calculations for ContentMergeViewer instances (where concrete type info is available after instantiation of a particular viewer). Fixes eclipse-platform/eclipse.platform.ui#1747
Here is how it looks like on Windows, comparing .project or .classpath files with each other with installed Textmate and no extra configuration needed: I would like to merge for M1, if there is any objections, please comment on PR's.
|
If no one finds time to review, you should use your own best judgment and feel empowered to proceed. |
Extend `contentMergeViewers` extension point: add an attribute to consider "linked" editor content type associations. The code checks if contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypes for the contentMergeViewers. Updated CompareViewerSwitchingPane to consider more precise title calculations for ContentMergeViewer instances (where concrete type info is available after instantiation of a particular viewer). Fixes eclipse-platform/eclipse.platform.ui#1747
Extend `contentMergeViewers` extension point: add an attribute to consider "linked" editor content type associations. The code checks if contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypes for the contentMergeViewers. Updated CompareViewerSwitchingPane to consider more precise title calculations for ContentMergeViewer instances (where concrete type info is available after instantiation of a particular viewer). Fixes eclipse-platform/eclipse.platform.ui#1747
Extend `contentMergeViewers` extension point: add an attribute to consider "linked" editor content type associations. The code checks if contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypes for the contentMergeViewers. Updated CompareViewerSwitchingPane to consider more precise title calculations for ContentMergeViewer instances (where concrete type info is available after instantiation of a particular viewer). Fixes eclipse-platform/eclipse.platform.ui#1747
This allows GenericEditorMergeViewer be used by compare editor for content types associated with the generic editor. Additionally implemented getTitle() to provide more specific compare editor description, so instead of default "Text Compare" one would see "XML Compare" etc. This avoids the problem of duplicated "Text Compare" options shown for different compare viewers (default one for plain text and the one for generic editor). See #1747 See eclipse-platform/eclipse.platform#1277
TextMergeViewer was expected by SaveableCompareEditorInputTest but more specific implementation (subclass of it) - GenericEditorMergeViewer was seen by the test after changes made to allow more specific viewer to "win" in the compare editor for text content. See eclipse-platform/eclipse.platform.ui#1747 See eclipse-platform#1277
TextMergeViewer was expected by SaveableCompareEditorInputTest but more specific implementation (subclass of it) - GenericEditorMergeViewer was seen by the test after changes made to allow more specific viewer to "win" in the compare editor for text content. See eclipse-platform/eclipse.platform.ui#1747 See #1277
I see that new feature only works in some cases, I've missed read-only diffs => need additional changes. |
Remember detected content type id in CompareConfiguration with the CONTENT_TYPE key. This value can be picked up as a hint by TextMergeViewer implementations (like GenericEditorMergeViewer) that need to know which content type was detected by compare editor. Most TextMergeViewer implementations don't need that hint because they aren't generic and usually always know which content type they will have - not so for GenericEditorMergeViewer which is generic. The hint allows GenericEditorMergeViewer to know for which content type was it actually created and so use that in cases where the content type can't be always derived from the input (like data from git revisions that don't have regular files or buffers associated to the viewer). See eclipse-platform/eclipse.platform.ui#1747
Detected content type id could be retrieved now from the CompareConfiguration with the CONTENT_TYPE key (see eclipse-platform/eclipse.platform#1294). Use this value (if available) as fallbackContentTypes in ExtensionBasedTextViewerConfiguration. The allows GenericEditorMergeViewer to know for which content type was it actually created and so use that in cases where the content type can't be derived from the input (like data from git revisions that don't have regular files or buffers associated to the viewer). Fixes eclipse-platform#1747
Remember detected content type id in CompareConfiguration with the CONTENT_TYPE key. This value can be picked up as a hint by TextMergeViewer implementations (like GenericEditorMergeViewer) that need to know which content type was detected by compare editor. Most TextMergeViewer implementations don't need that hint because they aren't generic and usually always know which content type they will have - not so for GenericEditorMergeViewer which is generic. The hint allows GenericEditorMergeViewer to know for which content type was it actually created and so use that in cases where the content type can't be always derived from the input (like data from git revisions that don't have regular files or buffers associated to the viewer). See eclipse-platform/eclipse.platform.ui#1747
Detected content type id could be retrieved now from the CompareConfiguration with the CONTENT_TYPE key (see eclipse-platform/eclipse.platform#1294). Use this value (if available) as fallbackContentTypes in ExtensionBasedTextViewerConfiguration. The allows GenericEditorMergeViewer to know for which content type was it actually created and so use that in cases where the content type can't be derived from the input (like data from git revisions that don't have regular files or buffers associated to the viewer). Fixes #1747
As noted on PR eclipse-platform#1277, the code looks weird and I can't explain what I smoke while writing it. Fixed the code to do what actually was meant. This is mostly paranoia code, as usually input.getName() is not null. See eclipse-platform#1277 See eclipse-platform/eclipse.platform.ui#1747
As noted on PR #1277, the code looks weird and I can't explain what I smoke while writing it. Fixed the code to do what actually was meant. This is mostly paranoia code, as usually input.getName() is not null. See #1277 See eclipse-platform/eclipse.platform.ui#1747
Moved from eclipse/tm4e#730.
Currently textmate (and generic editor) based editors seem not support syntax highlighting in compare editor.
Example: in 4.31 Eclipse, set "Generic Text Editor" as default for XML content type, select two
.project
files in Package Explorer and via right click run "Compare With... -> Each Other" command.That would show both parts of the editor without syntax highlighting:
That is of course not working for any other content type with textmate syntax support, XML here was chosen as it is simple to reproduce.
It would be nice if the syntax highlighting for all supported content types of generic editor also would be supported in compare editor.
During the discussion of this request, Mickael mentioned that:
and also:
The problem we have is that editor associations could be manually updated by user, but contentViewers/contentMergeViewers cannot, even if that would technically work (like in generic editor case), because they share same underlying implementation.
So my proposal would be to extend contentViewers/contentMergeViewers extension point and add an attribute to consider "linked" editor content type associations. The code could check if contentViewers/contentMergeViewers contribution refers to such "linked" editor id in extension, and check if editor supports other content types. In case there are more content types supported by same "linked" editor, these would be automatically considered as valid contentTypeBinding for the contentViewers/contentMergeViewers.
This shouldn't be that complicated. From compatibility point of view, since the extra extension attribute would be not set by default, none of existing code would be affected. For the generic text editor that would mean to mark its contentViewers/contentMergeViewers contributions "linked" to "org.eclipse.ui.genericeditor.GenericEditor" and that's it. Any "specialized" editor versions of generic editor (with dedicated editor id) shouldn't be affected either.
Once I have some time, I would try to provide a PR for that idea, but any comments / contributions welcome.
The text was updated successfully, but these errors were encountered: