Ticket #4141 (closed enhancement: fixed)

Opened 4 years ago

Last modified 21 months ago

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

Reported by: zaytsev Owned by: andrew_b
Priority: minor Milestone: 4.8.29
Component: mc-core Version: master
Keywords: Cc: ossi
Blocked By: Blocking: #2773, #3742
Branch state: merged Votes for changeset: committed-master

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 4 years 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 4 years ago by andrew_b (previous) (diff)

comment:2 Changed 4 years ago by zaytsev

  • Description modified (diff)

comment:3 Changed 4 years 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 4 years 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.

comment:5 Changed 21 months ago by andrew_b

  • Owner set to andrew_b
  • Status changed from new to accepted
  • Blocking 2773, 3742 added
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.29

Branch: 4141_mc.ext.ini
Initial changeset:67ec86b570be80da4670b57ae42be4ea71f8bb63

mx.ext was moved to INI format from custom one (yet another step to format unification). This allows to implement a task written in the ticket sunmmary.

This is alsow fixes #2773 and #3742.

comment:6 Changed 21 months ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:7 Changed 21 months ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

Merged to master: [3a3811c52857b2862cc41372792b9d3ac75092d0].

git log --pretty=oneline 1294c7bad..3a3811c52

comment:8 Changed 21 months ago by andrew_b

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.