This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
For mimeType "text/x-ant+xml" in the following FontColorSettingsFactory fcsf = EditorSettings.getDefault() .getFontColorSettings(new String[] { mimeType }); for(AttributeSet c : fcsf.getAllFontColors(profile)) { an empty collection is returned from fcsf.getAllFontColors(profile) The mimeType was obtained by doing DocumentUtilities.getMimeType(JEP) Interestingly, MimeLookup.getLookup(MimePath.get(mimeType)) seems to do something reasonable. FYI, fcsf.getAllFontColors(profile) is used to get a list of tokens as it appears in the OptionsDialog for the given "Language:".
BTW, I forgot to mention that I tried MimePath.get(mimeType) thinking that it might give something useful; but it produced a simple single element path text/x-ant+xml (which technically is correct). There's a hierarchy here: text/x-ant+xml text/xml and I know there's code somewhere in there that figures it out, since MimeLookup.getLookup(MimePath.get(mimeType)) .lookupResult(FontColorSettings.class); produces something that has that hierarchy embedded. If someone could point me to that parsing code, I could put together a workaround for my problem for nb7.0, while the general issue is addressed.
I couldn't find anything on how to parse something like text/xxx+yyy (probably because for current uses there is a provider that embeds each of the "children".) Is it as simple as text/xxx text/yyy Is something like text/xxx+yyy+zzz possible?
I tested with code: FontColorSettingsFactory fontColorSettings = EditorSettings.getDefault().getFontColorSettings(new String[] {"text/x-java"}); String currentFontColorProfile = EditorSettings.getDefault().getCurrentFontColorProfile(); Collection<AttributeSet> allFontColors = fontColorSettings.getAllFontColors(currentFontColorProfile); And allFontColors was not empty collection. There must be problem in client code.
And for mimetype "text/x-ant+xml" there are no profiles. I don't see any attributes set for ant in options dialog. If you give "text/xml" you get xml atributes sets
(In reply to comment #4) > And for mimetype "text/x-ant+xml" there are no profiles. I don't see any > attributes set for ant in options dialog. Since you see the same problem, "WORKSFORME" doesn't seem appropriate. The description indicates that starting with DocumentUtilities.getMimeType(JEP) There's no way to successfully use getAllFontColors() The NB mimetype syntax with "+" doesn't seem to have complete API support. comment #1 discusses the issue and shows some code that seems to show the inconsistency. If there were an API parser for the "+" mimetype syntax, at least something could be done. It might also be appropriate to throw an error if a code sees a mimetype with "+" and it doesn't handle it right.
There no tokens for ant, so there are no tokens for x/text-ant+xml. Or you expect that it merge ant tokens (none) with xml tokens (16)?
> expect that it merge ant tokens (none) with xml tokens (16)? I think this is what happens under the covers. I couldn't find much documentation on the "+" syntax and what is the right thing to do with it. In this situation merging gives results as expected. If it is possible to override colors, then a simple merge might not be best (though it would still be better). It might be that the mimeTypes infrastructure doesn't have sufficient API and documentation about working with the "+" syntax programatically.
Report from old NetBeans version. Due to code changes since it was reported likely to not happen. Feel free to reopen if happens in 8.0.2 or 8.1.
(In reply to Martin Balin from comment #8) > Report from old NetBeans version. Due to code changes since it was reported > likely to not happen. Feel free to reopen if happens in 8.0.2 or 8.1. Just tested with 8.1 and 8.0.2. Still happens. To reproduce: With jVi plugin installed - open a build.xml observe WARNING [org.netbeans.modules.jvi.FontTracking]: fcsf.getAllFontColors(profile) empty for 'text/x-ant+xml (text/x-ant+xml)' in the logfile. Note: the problem is that compound mime types (those with "+") are not being handled well. And there is little (or none?) API support for working with a mimetype that has "+". Read the comments. ((I wonder if @mbalin was simply tasked to close everything old. That could be ok. But putting Due to code changes since it was reported likely to not happen. in the comment is BS; it gives the impression that there was actually some analysis of the bug performed.))
BTW, some simple API support, as mentioned in comment #5, would help a lot.