Summary: | Discover editors bound to specific already associated file names | ||
---|---|---|---|
Product: | Community | Reporter: | Konstantin Komissarchik <konstantin> |
Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
Status: | CLOSED MOVED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | mikael.barbero, mistria, peter |
Version: | unspecified | Keywords: | feep |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Konstantin Komissarchik
2016-05-19 12:42:17 EDT
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. |