Community
Participate
Working Groups
Users should be able to use content-type to define editor associations.
Would you please describe the benefits and use cases served by this one?
The benefits are that: 1. it allows end-users to understand where a file/editor association is provided. Currently, only File/editor mapping are shown (and editable) as preferences, and user don't get a chance to understand what defines other (content-type based) associations 2. As user can define content-types, the next natural action they'd like to do once the content-type is defined is to associate an editor with it. At the moment, defining content-type still requires to use a File/Editor association to associate new types with editors 3. It's an iteration in favor of bug 91965 , which makes a lot of sense as File/Editor association and Content-type/editors association are somehow redundant and content-types are much more powerful (as they allow multiple name patterns, resolution against *content* additionally to file name, a hierarchy, encoding...) 4. Developers and users playing with LSP4E and TM4E (which can allow dynamic registrations of servers/grammars for a content-type) may want to associate the Generic Editor with the content-type once they have added support for LSP and TM for this content-type
Gerrit change https://git.eclipse.org/r/101091 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8b9ee3a70e2197ed641a8a74666f3303b8adc6de
Keeping the bug open to track N&N and Documentation.
New Gerrit change created: https://git.eclipse.org/r/101951
New Gerrit change created: https://git.eclipse.org/r/101977
I assume you have not installed API Tools (baseline), otherwise you would have seen the error on the version number. It's also reported by the build: http://download.eclipse.org/eclipse/downloads/drops4/I20170725-2000/apitools/analysis/html/org.eclipse.ui.workbench/report.html Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=59f608d08265b097a43669cc04eab202369e448f
(In reply to Dani Megert from comment #7) > I assume you have not installed API Tools (baseline), otherwise you would > have seen the error on the version number. Now you point it out, I can see it, but as it one drown between all other warnings of the bundle, I missed it. Sorry about that. I've applied the rule from the wiki about increasing the minor segment "Another way to know when this version number should be changed is by exclusion: it should indicate changes that are neither bug fixes (indicated by the service segment) nor breaking API changes (indicated by the major segment)", that seems to apply here. In such case, it would still miss as API Tool filter to avoid the warning, so it's not really an excuse ;) However, can you please clarify which of +0.0.100 or +0.1.0 is best for new features (with new "internal" API) ? Maybe there is a better way to state the rules in the wiki to avoid confusion. > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=59f608d08265b097a43669cc04eab202369e448f Thanks a lot.
(In reply to Mickael Istria from comment #8) > (In reply to Dani Megert from comment #7) > > I assume you have not installed API Tools (baseline), otherwise you would > > have seen the error on the version number. > > Now you point it out, I can see it, but as it one drown between all other > warnings of the bundle, I missed it. Sorry about that. This is yet another reason why I request people to spend time on cleaning up bundles whenever they have to touch them for some reason. Please do pre|post cleanup commits so at some point we come up with manageable state. > > I've applied the rule from the wiki about increasing the minor segment > "Another way to know when this version number should be changed is by > exclusion: it should indicate changes that are neither bug fixes (indicated > by the service segment) nor breaking API changes (indicated by the major > segment)", that seems to apply here. > In such case, it would still miss as API Tool filter to avoid the warning, > so it's not really an excuse ;) > However, can you please clarify which of +0.0.100 or +0.1.0 is best for new > features (with new "internal" API) ? Maybe there is a better way to state > the rules in the wiki to avoid confusion. > > > Fixed with > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=59f608d08265b097a43669cc04eab202369e448f > > Thanks a lot.
(In reply to Mickael Istria from comment #8) > (In reply to Dani Megert from comment #7) > > I assume you have not installed API Tools (baseline), otherwise you would > > have seen the error on the version number. > > Now you point it out, I can see it, but as it one drown between all other > warnings of the bundle, I missed it. Sorry about that. Ah! It looks like that problem is not explicitly set in the bundle and hence the workspace value is used. I've set that to 'Error' in my workspace. I guess we should do this explicitly on the bundle. > However, can you please clarify which of +0.0.100 or +0.1.0 is best for new > features (with new "internal" API) ? Maybe there is a better way to state > the rules in the wiki to avoid confusion. There is no clear rule. I think if a bigger feature or UI change is made the minor should be updated but not when an existing UI is slightly modified.
Gerrit change https://git.eclipse.org/r/101951 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=2be6d4d72bf7d9128c5788f1c253636841a8f4e0
Gerrit change https://git.eclipse.org/r/101977 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a11b61cbcfd3e6225d32f515023f33d5e0a5a80c
All patches merged. Thanks to Alex, Lucas and Kalyan for your help.
