Community
Participate
Working Groups
Local files in regular CDT projects are being opened in the RDT remote editor. This causes ProjectNotConfiguredExceptions whenever you try to do anything.
There is really nothing we can do about this. Both editors are registered against the same content types, and there is no way to express any additional conditions on when one editor should be preferred over another. The current Eclipse behaviour is that the last editor contributed wins. As a workaround, we should perhaps make it so that if the exception happens, we fall back to selecting the local provider. It still won't bring up the actual CDT editor, but at least things will largely work by default, and hence the user may not really notice a difference. Also, if we can make the remote editor visually look different than the regular CDT one in some subtle way (a different icon or something), then perhaps users would be able to notice that the wrong editor is being used and go in and select the one they prefer.
I noticed this too and meant to file a bug a couple of weeks ago. It's very disconcerting. So as soon as you make a project a remote project, the editor that opens for it is the remote editor, then if you create or open a file in a local project, it too gets opened in the remote C/C++ editor ( you can see that title flash in the title tab as it's opening). That's the behavior I thought I saw. How do you determine to use the remote editor for that first file? Something different is happening there. Could you reset the 'last type of editor used' after using this editor? So if you 'open with...' to get the local editor back as the last one used, local files will get opened with that one after that, right?
Another thought we had was putting some code in the RDT editor to check if the project was remote or not, and if not open the other editor and close itself. This is rather a hack though, and doesn't cover the case where you have an external file open (because it has no project).
I've put in a request for a new icon for the editor. That will be a start at least.
I have made it so that the Remote C/C++ Editor now always shows a unique icon. The icon I used is temporary until we get a hopefully better one from the Media Department. Any further ideas we've had on getting the proper editor to show have not panned out thus far.
I tried a hare-brained scheme involving creating a set of new, remote content types that extended from the CDT types. The idea with this is that there is a mechanism that allows you to map content types to project natures, so if you say had the remote nature, we could express that our new content type should be used. The problem though is that for the rest of CDT to work, our new content types had to extend from the old ones, in which case Eclipse seemed to think our new content type and the editor association for it were so redundant that they weren't even listed as options unless you went to open a file with "Other editors..." (or whatever it was called). So for now, I declare defeat on this bug. I think the only way to get this to work is by getting the Platform to provide an update to the content type system. I'll open a bug against the platform for this if there isn't one already.
*** Bug 251453 has been marked as a duplicate of this bug. ***
Why not just have the remote editor work properly on local projects, since it's meant to be the same as the CEditor anyway? That way it wouldn't matter which editor was opened. If the icon was the same, then no-one would even notice.
(In reply to comment #8) > Why not just have the remote editor work properly on local projects, since it's > meant to be the same as the CEditor anyway? That way it wouldn't matter which > editor was opened. If the icon was the same, then no-one would even notice. This is a bit tricky... On a regular CDT project, there is no service model. So there's no real way to get at the local providers this way (the local providers are currently incomplete to boot...)
If it was possible to hard-code some default local service providers, it might be a acceptable work around for this problem though. As long as the behavior is the same, I don't think people would object to using the RDT editor on local projects when RDT was installed.
With the fix in bug 244839, the remote editor can now handle local content. As a result I'm going to downgrade this.
Assuming this will not be fixed.
