Community
Participate
Working Groups
Bug 219570 introduced an option to link Sync view with editors, but it doesn't work with compare editors.
Setting an IElementComparer which is aware of SyncInfoModelElements and is able to match them with IResources or IResourceVariants (which is basically what the fix for bug 291215 does) would fix this issue as well. However linking from Sync View to compare editors is a little bit harder since compare editors do not work with FileEditorInputs so the method org.eclipse.ui.internal.WorkbenchPage.findEditor(IEditorInput) will return null. Of course, compare editor can adapt to IEditorInput but this will work only if the editor active. So my question to Dani is: are you OK with having an option to link (Link with Editor + Show In) from a compare editor to sync view but not the other way (from view to a compare editor)? If yes I would be happy to update the bug so it no longer blocks bug 219570 and change the summary to something like "Linking from sync view to compare editors doesn't work". What do you think?
As a first step I'm happy with it but for final 3.6 it should work in both directions. Personally I will not miss Sync > Compare Editor because I use single click ;-)
Created attachment 159165 [details] Fix v01 EditorMatchingStrategy for Compare Editors.
Created attachment 159166 [details] mylyn/context/zip
Created attachment 159412 [details] Fix v02 A much better fix. The previous one was giving to many false positives.
Implementing IEditorMatchingStrategy is a very convenient way of fixing this bug, but it has a side effect: if a compare editor for a file is opened it will be brought to the top if a user opens the file from Package Explorer (for instance). This differs from current behavior where, in reaction to opening a file, the compare editor will be activated only if it's already on the top of editors stack (iirc this is true only for Java files, as our rationale was that the Java Compare started to be more like regular Java editor - bug 169386). Otherwise a regular editor for the file will be opened. This is a natural consequence of having a custom matching strategy associated with compare editor. However I'm not sue if such 'side effect' is acceptable. If no, I could try to get references to all editors opened and return 'false' when matching with a compare editor when a regular one is available. Dani, what do you think?
> However I'm not sue if such 'side effect' is acceptable. >Dani, what do you think? That would not be acceptable. In fact there are still voices that also don't like the current "open" behavior where we don't open/activate the Java editor if the compare editor is the active one.
Created attachment 159772 [details] Fix v03
(In reply to comment #8) > Created an attachment (id=159772) > Fix v03 ... has the same matching logic as in EditorMatchingStrategy from 'Fix v02', but this time it is used by Sync view only. Regular editors are preferred to compare editors.
The latest fix applied to HEAD, available in builds >I20100223-0800.
