update to new mimeapps.list specification

[Vladimir Kudrya]

On 15.04.2014 23:59, David Faure wrote:
> On Monday 14 April 2014 10:42:35 Vladimir Kudrya wrote:
>> Please clarify this:
>> "add to the blacklist the names of any desktop files found in the same
>> directory as the mimeapps.list file"
>
> You find foo.desktop (associated with the given mimetype), you add foo.desktop
> to the result list, but then you add foo.desktop to the blacklist too, so that
> you don't add foo.desktop again.
>
>> How "temporary" the blackist is in this algorithm?
>
> Temporary until the end of the algorithm :-)
>
>> If we are dealing with actions (add/remove), then why not to reduce
>> complexity of the algoritm and just compose *one* list of associations
>> from global to local by taking described actions?
>>
>> 1. go to the most global dir
>> 2. Add from .desktop's
>> 3. Add according to mimeapps.list
>> 4. Remove according to mimeapps.list
>> 5. move to next more local dir
>> 6. goto 2
>
> Yes, that should be equivalent, and is the whole point of how added/removed
> works. However, if you only need the first N apps to show in a list, then
> better start from the other side (most-local first).
>
> And if you only need to find the default application, then better start from
> the most-local dir too (since you can stop as soon as you find one that is
> installed).
>
> So overall, it's simpler to only have algorithms that start from most-local,
> than to have both kinds depending on the use case.
>
> But of course you are free to implement it starting from most-global and going
> up. An algorithm in a spec is just a suggestion, and helps understanding, it's
> not the only way to implement it.
>

OK, now I finally have the full picture. And I find the spec misleading, 
the way it is written now. I suggest you first describe the essence of 
the algorithm global>local way, since it is in fact the "natural", 
"uncompressed" logic of the algorithm. And then give an example of how 
it can be reordered to achieve optimal performance.
Well, human-digestible form first, machine-digestible form after that ;)