Community
Participate
Working Groups
In Bug 480176, marketplace listings can be tagged as including editors for specific extensions. When a user opens a file with an unknown extension, the marketplace is searched and appropriate solutions are offered to the user. We should extend this by allowing solutions to advertise editors for specific file names. It's common to have custom editors for files with set names, such as web.xml, application.xml, weblogic.xml, etc. The tricky part is that we'd need to revise the launch logic as now we'd have to deal with editor precedence (there is already an editor for xml files at Eclipse). Architecturally, this could work by downloading and caching (to disk with expiration) information about available solutions. Then when a file is opened, we first try to match full file name (installed and in marketplace) then by extension (installed and in marketplace).
A first step would be to allow to search an editor based on full file-name. The current discovery strategy may be able it support it without too much change. Once we have this search ready, we could already ship it to users via "Open With > Search alternative editors on marketplace..." context-menu or so. Once we have this search, then we can imagine additionally to checking for compatible editors during the launch of unassociated files, to also check for them also when opening an editor inside Eclipse (by implementing it as a workbench listener triggered on editor open). > Then when a file is opened, we first try to match full file name (installed and in marketplace) then by extension (installed and in marketplace). That would require a major change in the IDE.openFile methods. Currently, there is a way to extend and choose how to handle opening unassociated files only. Here it's changing the way how all file openings are handled.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/250.
