Closed iloveeclipse closed 7 months ago
I have no idea what needs to be done to achieve this. If you can give me some hints I can have a look at it.
Enabling (some) generic editor features in the compare viewer has to be declared per content-type, ideally by the same bundle as the one that defines the content-type association with generic editor. Eg from Wild Web Developer https://github.com/eclipse-wildwebdeveloper/wildwebdeveloper/blob/13c104d642e17156c7308ce43a78ccb04edcb55e/org.eclipse.wildwebdeveloper/plugin.xml#L1273C4-L1286C16
<extension
point="org.eclipse.compare.contentViewers">
<contentTypeBinding
contentTypeId="org.eclipse.wildwebdeveloper.parent"
contentViewerId="org.eclipse.ui.genericeditor.compareViewer">
</contentTypeBinding>
</extension>
<extension
point="org.eclipse.compare.contentMergeViewers">
<contentTypeBinding
contentMergeViewerId="org.eclipse.ui.genericeditor.compareViewer"
contentTypeId="org.eclipse.wildwebdeveloper.parent">
</contentTypeBinding>
</extension>
generic editor features in the compare viewer has to be declared per content-type
Hmm. So if I have editor (like generic one) that can be used with multiple content types and also that can be assigned to be opened for a new content type by user, why can't we be more clever in the platform and automatically use that "org.eclipse.ui.genericeditor.compareViewer" for the content type in comlare editor?
why can't we be more clever in the platform and automatically use that "org.eclipse.ui.genericeditor.compareViewer" for the content type in comlare editor
Note that the generic editor isn't referenced directly here, it's a separate id/object that is assigned to the compare viewer, and there is no declarative mapping between this object and the underlying text editor. So it's not trivial to infer the proper compare viewer from the editor association. But if you think it's doable, that would indeed be an interesting improvement for Platform.
Note that the generic editor isn't referenced directly here, it's a separate id/object that is assigned to the compare viewer, and there is no declarative mapping between this object and the underlying text editor.
Arrgh, I see it now.
not trivial to infer the proper compare viewer from the editor association. But if you think it's doable, that would indeed be an interesting improvement for Platform.
One could one (compare contribution) refer to other in extension, and check for that. Tha shouldn't be complicated. The major question is if there are cases where editor-to-content type association shouldn't be considered in compare-editor-to-content type usage?
But if that would be the case, as we would only change generic editor, we should be mostly safe, I don't think there is a an extension of org.eclipse.ui.genericeditor.compareViewer that would be broken if used in context of a different content type?
@iloveeclipse I registered the language pack provided content types with the generic compare viewer. I think this is all we can do within the tm4e project. I'd suggest to close this issue.
Sure, I will try to follow up on platform side.
Sure, I will try to follow up on platform side.
See https://github.com/eclipse-platform/eclipse.platform.ui/issues/1747
Currently textmate based editors seem not support syntax highlighting in compare editors. 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 also would be supported in compare editor.