Community
Participate
Working Groups
I suggest a configuration setting in General / File associations to set the editor to be used for unknown file types. Currently, the OS default editor is opened. I suggest: Editor for unknown file types: ( ) Default system editor ( ) This editor: << List of editors >>
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
We should also think if we can automatically recognize "text" or other content types via some magic [1] and so automatically open meaningful editors (e.g default text editor for all unknown "text" files). Not sure if IContentDescriber can be used here. [1] http://en.wikipedia.org/wiki/Magic_number_%28programming%29
Similarly to what OS do in that case, when no obviously good editor is found, Eclipse could show a "Select Editor" UI (pop-up, or even an editor itself) that would allow user to select an existing editor and have a checkbox to opt-in remember association.
I like Andrey's suggestion, but I would take it a bit further. If we don't know what the content type is, we should default to the text editor, whether the file is text or not. That's essentially what happens when there is no System editor for the file type. This is really important because I've seen competing IDE's register against files that should be opening up in Eclipse when you double click them. For example, Xcode registers for .sh files which are commonly bash scripts. It's pretty embarrassing when a user double clicks on a file and a competitor's IDE comes up. I believe the reason we defaulted to System editor was to handle files that were managed by Windows applications. For example, double clicking xls files opened Excel. I'm not sure that's really a high runner use case any more, and I'm pretty sure it's lower than text files that don't have content types registered to them. At the very least, we still have the open System editor the user can use to open those files. BTW, Kaloyan Raev from Zend has a plug-in up on the Marketplace that does just that. https://marketplace.eclipse.org/content/default-text-editor
Another approach would be to have an "unknown" symbolic content type in preferences, and to be able to associate it with editors. So user could customize the behaviour without new concepts, and extenders could also do the same.
*** Bug 433296 has been marked as a duplicate of this bug. ***
I'm experimenting around an extension point to plug strategies on how to handle unassociated file types. The default one would remain the current "System editor then Text", and I'll try 2 alternative extensions for "Let user select editor" and "Poll a remote suggestion/discovery service". The choice between the strategy would be managed as a preference, that RCP providers could set via plugin_customization.ini and/or API; and that user could set via preference page.
New Gerrit change created: https://git.eclipse.org/r/62659
(In reply to Mickael Istria from comment #9) > I'm experimenting around an extension point to plug strategies on how to > handle unassociated file types. The default one would remain the current > "System editor then Text", and I'll try 2 alternative extensions for "Let > user select editor" and "Poll a remote suggestion/discovery service". > The choice between the strategy would be managed as a preference, that RCP > providers could set via plugin_customization.ini and/or API; and that user > could set via preference page. See suggested patch: https://git.eclipse.org/r/#/c/62659/ It comes with 2 strategy: * Default/current one: choose system editor or text editor * Ask user via pop-up (shows same pop-up as open with) Use can select the strategy to use in the File Association preference page; extenders can plug additional strategy and use regular preferences to enable one or the other as default.
Gerrit change https://git.eclipse.org/r/62659 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f18d9fb292fe254ae18c96fb2a36a97951821d93
Thanks Mickael!
Thanks Mickael! I really like the solution. I found a small issue while testing it - bug 485201.
*** Bug 142228 has been marked as a duplicate of this bug. ***
Thanks Mickael. Can you also upload a N&N entry?
New Gerrit change created: https://git.eclipse.org/r/63609
New Gerrit change created: https://git.eclipse.org/r/63610
Gerrit change https://git.eclipse.org/r/63609 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a9dbe8311173f059d53caec541b5797206de7be0
Gerrit change https://git.eclipse.org/r/63610 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=375609cf123b5457da700945a23a8a4c8894b174
There are a few
The implementation broke APIs, see bug 486665 comment 1. I'll probably remove the feature from the N&N until it's clear how the solution in M6 will look like.
