Community
Participate
Working Groups
The action of opening a file with a non-default editor should result in future file edits opening the non-default editor. The eclipse navigator view shows the following behaviour: 1) double click on file and the default editor as specified in the file associations preference should be used to open the file 2) make sure the editor is closed 3) RMB on the file and select to open with a different editor (the default editor will have a bullet beside it in the popup menu - the different editor (non-default) should be used to open the file 4) close the editor 5) opening the file with any editor should make it the default 6) There is a "default editor" action in the RMB popup that opens the file with the default editor as specified in the file assocations. Using this action will also reset the file's editor back to the preference default. RSE differs from this behaviour by not properly updating the new default. It appears that once a non-default editor has been chosen once it becomes the "default editor". I could not find a way to reset it back to the proper default editor. It was only by explicitly opening the file with the editor I wanted could I get the desired behaviour This affects other eclipse components that use the PlatformUI to get the default editor id. They may get a different answer which with either open 2 editors on the same file or get an error about the file is already in use.
The problem is that, via the reusable cached SystemEditableRemoteFile, RSE keeps the original editor descriptor. In RSE 3.2, there is no API to change the editor descriptor but it is possible to circumvent that by using reflection.
Created attachment 179054 [details] patch to use reflection to set editor descriptor
Alan, could you see if this patch fixes the problem?
I've committed the change to the HEAD stream and opened bug 325601 for the backport to the R3_2_maintenance stream.
Marking as fixed.
Created attachment 179129 [details] 3.3 version patch with set/get API for editor descriptor For 3.3, since we can make binary compatible API changes, I've got a patch that doesn't use reflection.
Marking this patch committed to 3.3
(In reply to comment #4) > I've committed the change to the HEAD stream and opened bug 325601 for the > backport to the R3_2_maintenance stream. Dave - it looks like bug 325601 is for the R3_1_maintenance Stream, is this intentional ? For now, this fix is *not* committed / released to R3_2_maintenance.
(In reply to comment #8) > (In reply to comment #4) > > I've committed the change to the HEAD stream and opened bug 325601 for the > > backport to the R3_2_maintenance stream. > > Dave - it looks like bug 325601 is for the R3_1_maintenance Stream, is this > intentional ? For now, this fix is *not* committed / released to > R3_2_maintenance. It is for the R3_2_maintenance stream. I think the target milestone was off.
*** Bug 284598 has been marked as a duplicate of this bug. ***
Since this is a dup of bug 284598 I understand that API has been added to support this?
(In reply to comment #11) > Since this is a dup of bug 284598 I understand that API has been added to > support this? Yes, API was added.
