Bug 200768

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.