No subject

rather as a sort of "dumbing down" (?). I think we should write
this spec so that advanced implementations are able to keep their
advanced features, while less-advanced would have suitable fallbacks.

>> As you said above, we'll have at least to implement DES parameters,
>> replacing URLs with URIs:
>=20
> while I'm fine with the four above, I don't see a reason for the next=20
> three...
>=20
>> - %i: --icon iconname
>> - %c: translated label of the item
>> - %k: URI of the desktop file

They are directly taken from DES ;-)
Nonetheless, I agree that I don't well see their usefulness.

>> plus (from N-A):
>> - %d: (first) base directory
>=20
> maybe %D for a space separated list of them (in a tree view selected=20
> items don't always have the same dirname)

Yes.

>> - %h: hostname of the (first) URI
>> - %m: space-separated list of basenames
>=20
> hmm.. that's not very intuitive. I would stick to the policy of having
> a lower case letter for a single item and the same letter upercase for
> a space separated list of them.
> What speeks against %b and %B for the basename and a list of them? We=20
> could keep %m as deprecated alias for %B for compatibility.

I agree for %b and %B.
Not needed to specified that %m is deprecated: it is up to the
implementation to read its own old files.

>> - %p: port number of the (first) URI
>> - %s: scheme of the (first) URI
>> - %n: username of the (first) URI
>=20
> For completeness we could add %x (and %X) for the extension (the list=20
> thereof). In midnight commander %b is the basename *without* =20
> extension. But I think we should keep the basename with extension, =20
> just like the utile 'basename' returns it. Do you have a nice idea =20
> which letter could be used for the basename without extension?

None obvious (document, filename, name, basename are already taken)
Say %w/%W (for 'without') ?

I'd be able to write a third draft in next days (oop's, tomorrow is
already reserved - say next week)

Regards
Pierre