Allow compound (AND) conditions in mc.ext to disambiguate overloaded extensions

[zaytsev]

It would be awesome if someone did something to ts - right now it is always regarded as a video file. This might have been reasonable before the advent of TypeScript, but now most of TS-files are actually code.

shell/i/.ts
type/^data$
    Open=...

zaytsev@parallels:~/src/app/src$ file main.ts 
main.ts: Java source, ASCII text

zaytsev@parallels:~/src/app/src$ file typings.d.ts 
typings.d.ts: ASCII text

zaytsev@parallels:~/src/app/src$ file test.ts 
test.ts: Java source, UTF-8 Unicode text

zaytsev@parallels:~/src$ file sample_640x360.ts 
sample_640x360.ts: data

zaytsev@parallels:~/src$ file ed24p_10.ts 
ed24p_10.ts: data

file qt/translations/qt_ru.ts
qt/translations/qt_ru.ts: XML 1.0 document, UTF-8 Unicode text, with very long lines

Spun off from #4128. Relates #2118.

[andrew_b]

I think we should port mc.ext to ini format. Ini allows us to make any complicated logic easier than current format.

shell/i/.ts
type/^data$
    Open=...

will be like following:

[Some title]
shell=ts
shell_ignore_case=true
type=^data$
open=...

[zaytsev]

In #2118 ossi argued for an own mailcap parser and migration of mc.ext to mailcap:

​https://tools.ietf.org/rfc/rfc1524.txt

If one goes as far as to say, that we want to change the format, maybe this should be carefully considered again.

I've briefly looked at mailcap spec, and so far I'm not sure if we can actually convert mc.ext to it - it doesn't offer any way to filter by extension or specify compound conditions - like mime-type AND extension :-(

[ossi]

it doesn't offer any way to filter by extension or specify compound conditions

yes, but it shouldn't be required - the mailcap approach completely separates type detection and type handling. mc.ext is so messy because it does both.

but let's not get carried away in this rather specific ticket, as i don't suppose anyone is volunteering for a massive rewrite of that infra right now. my proposal to support ANDs is a rather minimal approach that should be doable with just a few LOC (it's not even necessary to support arbitrarily many conditions, only a single additional one), and i'd give that a shot myself. feel free to spin off a big-picture ticket as a successor to #2118.