Ticket #4141 (new enhancement)
Allow compound (AND) conditions in mc.ext to disambiguate overloaded extensions
Reported by: | zaytsev | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | Future Releases |
Component: | mc-core | Version: | master |
Keywords: | Cc: | ossi | |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description (last modified by zaytsev) (diff)
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
Change History
comment:3 Changed 19 months ago by zaytsev
- Cc ossi added
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 :-(
comment:4 Changed 19 months ago by 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.
I think we should port mc.ext to ini format. Ini allows us to make any complicated logic easier than current format.
will be like following: