Bugzilla – Full Text Bug Listing
|
Description
David Neal
*** Bug 129747 has been marked as a duplicate of this bug. *** The best (if implementation would be possible) would be to check filenames by the standard regex pattern(s) to define associations. This would allow for all the imaginable combinations to get configured properly. Upvoting the solution. Just for reference, this would solve bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=292229 too. I'd like to see this added for 4.8. I'm assigning this to myself so it shows up in my todo list, but if anyone is also interested, I'd be glad to change assignment so it goes to the first one able to fix it. The entry points to add this would be: * org.eclipse.ui.internal.registry.FileEditorMapping (and probably interface IFileEditorMapping to add a new method, but it's no API issue as it's mark as @noimplement) * org.eclipse.ui.internal.dialogs.ContentTypePreferencesPage.Spec to add the regexp as a field Then everything that reads the name or the extension of those 2 classes sould be augmented to also read the regexp, and the FileExtensionDialog should allow patterns It does seem like a too hard piece of work to do. (In reply to Mickael Istria from comment #4) > The entry points to add this would be: > * org.eclipse.ui.internal.registry.FileEditorMapping (and probably interface > IFileEditorMapping to add a new method, but it's no API issue as it's mark > as @noimplement) > * org.eclipse.ui.internal.dialogs.ContentTypePreferencesPage.Spec > to add the regexp as a field > > Then everything that reads the name or the extension of those 2 classes > sould be augmented to also read the regexp, and the FileExtensionDialog > should allow patterns > > It does seem like a too hard piece of work to do. Will the pattern matching associations have a lower priority compared with the perfect match associations? Tentative for 4.8.M2. I've started to work on a patch and I believe it should be ready next week (too late for 4.8.M1) (In reply to Mickael Istria from comment #6) > Tentative for 4.8.M2. I've started to work on a patch and I believe it > should be ready next week (too late for 4.8.M1) WIP: https://github.com/mickaelistria/eclipse.platform.runtime/tree/263316 and https://github.com/mickaelistria/eclipse.platform.resources/tree/263316 New Gerrit change created: https://git.eclipse.org/r/102464 New Gerrit change created: https://git.eclipse.org/r/102466 New Gerrit change created: https://git.eclipse.org/r/102569 Gerrit change https://git.eclipse.org/r/102466 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=85b23928b9d76e3b2ed9aeca2df0c520a79040ca Gerrit change https://git.eclipse.org/r/102464 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=28cac80c5be28e7e7ba0f45222e89c94a53fb902 Gerrit change https://git.eclipse.org/r/102569 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=27d9147d1936b26b7c4adf326993f921e48d00b4 New Gerrit change created: https://git.eclipse.org/r/104028 Gerrit change https://git.eclipse.org/r/104028 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=64665e711c66f88e417306ec10c21bc3d3302efc Please add image to the N&N entry. (In reply to Alexander Kurtakov from comment #16) > Please add image to the N&N entry. Done. I am trying this pattern-based content-type definitions at the moment and I am running into problems. When I define:
<file-association
content-type="org.springframework.boot.ide.properties.application.properties"
file-names="application.properties">
</file-association>
The file called "application.properties" gets this content-type and the associated editor/icon shows up in the package explorer.
If I instead define:
<file-association
content-type="org.springframework.boot.ide.properties.application.properties"
file-patterns="*application*.properties">
</file-association>
The associated editor/icon doesn't show up, looks like this content-type gets ignored for a file called "application.properties".
When I debug into ContentTypeCatalog.internalFindContentTypesFor, it finds the regexp-based content-type, but it is not used later, looks like the extension-based content-type that matches here (for Java properties) is selected instead.
Is there a way to get my regexp-based content-type association being selected instead of the Java properties type?
(In reply to Martin Lippert from comment #18) > When I debug into ContentTypeCatalog.internalFindContentTypesFor, it finds > the regexp-based content-type, but it is not used later, looks like the > extension-based content-type that matches here (for Java properties) is > selected instead. Did you mark you content-type as extending JDT properties content-type? I think it's necessary if you want to make sure it's going to be the one returned as IIRC the ContentTypeManager returns the "most specialized" one in case it finds multiple content-type. If you don't define you type as extending base properties type, then it doesn't seem more specialized and the ContentTypeManager may return one or the other, and would be right for both. Good point. I changed this, but my content type still isn't being selected. Here is the full extension declaration:
<extension
point="org.eclipse.core.contenttype.contentTypes">
<content-type
id="org.springframework.boot.ide.properties.application.properties"
base-type="org.eclipse.jdt.core.javaProperties"
name="Spring Properties File"
priority="high">
</content-type>
<file-association
content-type="org.springframework.boot.ide.properties.application.properties"
file-patterns="*application*.properties">
</file-association>
</extension>
Any idea what might be going wrong here?
(In reply to Martin Lippert from comment #20) > Any idea what might be going wrong here? Nope. Please open a separate bug about it as it could be a bug in Platform. *** Bug 22905 has been marked as a duplicate of this bug. *** *** Bug 89859 has been marked as a duplicate of this bug. *** *** Bug 46297 has been marked as a duplicate of this bug. *** |