Ticket #4141 (new enhancement)

Opened 22 months ago

Last modified 22 months ago

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.

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.

Change History

comment:1 Changed 22 months ago by andrew_b

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:

[Some title]
Last edited 22 months ago by andrew_b (previous) (diff)

comment:2 Changed 22 months ago by zaytsev

  • Description modified (diff)

comment:3 Changed 22 months ago by zaytsev

  • Cc ossi added

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


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 22 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.

Note: See TracTickets for help on using tickets.