(In reply to comment #0)
> Hi hadess, thanks for going through the shared-mime-info bugs [should you be
> the default owner of new bugs?].

That's fine, I'm already on the CC: for all the bugs.

> Here's a new one. This is from the current freedesktop.xml.in:
> 
>   <mime-type type="text/x-readme">
>     <sub-class-of type="text/plain"/>
>     <_comment>README document</_comment>
>     <glob pattern="README*"/>
>   </mime-type>
> 
> Can I request the removal of this glob? It makes a file called README.pdf open
> up in a text editor, which is definitely not what the author of the file
> intended (it's really a PDF file).

I've added a test case to the test suite for that, and a README.pdf file will get appropriately the application/pdf mime-type.

> In fact I don't see what text/x-readme is useful for, for real plain-text
> readme files, text/plain seems ok. There isn't any text/x-readme specific
> application, is there? (can't find any on my system)

Any text editor will be able to open those README files, obviously, but the main use is to have a README specific icon.

> I see that it's used as a base-class for text/x-nfo, but we could make x-nfo
> inherit text/plain directly instead.

As I mentioned, I don't think there's a problem with the matching, but it could be made clearer in the spec that trailing globs take precedence over leading globs (ie. *.pdf takes precedence over README*).

> README.pdf file will get appropriately the application/pdf mime-type.

That's implementation dependent at this point. In KDE it gets text/x-readme. This is because we (mostly Alex and I) discussed on xdg-list that "the longest glob match wins", which does make sense in other cases. For instance, if you don't have that rule, then README.txt is text/plain, not text/x-readme as you would want.

> Any text editor will be able to open those README files

Only if really are plain text, unlike README.pdf

> trailing globs take precedence over leading globs (ie. *.pdf takes precedence over README*)

I object. This breaks README.txt as I mentionned. 

I think the real solution lies in "glob weights", as suggested on xdg-list by Alex and I. If the README.* glob was assigned a very low weight, then it would be used as a last-resort fallback, after ensuring that the file isn't PDF or any other known type first.
AFAIK the current status is that glob weights have been added to the spec, but not to the code?

> the main use is to have a README specific icon

That's fine but only if it doesn't break the user experience by opening the wrong application. I.e. I think it's fine if README.pdf gets a pdf icon instead -- in fact, it's the only solution, as long as we stick with the (very sensible) notion that the icon is mimetype-dependent :)

(In reply to comment #2)
> > README.pdf file will get appropriately the application/pdf mime-type.
> 
> That's implementation dependent at this point. In KDE it gets text/x-readme.
> This is because we (mostly Alex and I) discussed on xdg-list that "the longest
> glob match wins", which does make sense in other cases. For instance, if you
> don't have that rule, then README.txt is text/plain, not text/x-readme as you
> would want.

Which implementation are you using? Are you not using xdgmime? That's what the test suite is based on.

Would using a low priority for README not be enough? I've added a weight of 10 for the README* glob.

No we are not using xdgmime, I implemented the shared-mime-info spec in KDE.
(We use update-mime-database of course, so I'm simply parsing its output)

Ah I see, I have to parse globs2 instead of globs2 now :)
OK. But thanks for the glob pattern priority change, it will help.