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

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/4141
Reporter	zaytsev (@zyv)
Mentions	ossi (@ossilator)

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.

[mc-butler]

Changed by andrew_b (@aborodin) on Nov 2, 2020 at 13:42 UTC (comment 1)

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

[mc-butler]

Changed by zaytsev (@zyv) on Nov 2, 2020 at 13:56 UTC (comment 2)

• Description edited

[mc-butler]

Changed by zaytsev (@zyv) on Nov 2, 2020 at 14:03 UTC (comment 3)

• Cc set to ossi

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 :-(

[mc-butler]

Changed by ossi (@ossilator) on Nov 2, 2020 at 14:35 UTC (comment 4)

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.

[mc-butler]

Changed by andrew_b (@aborodin) on Sep 17, 2022 at 11:38 UTC (comment 5)

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

Branch: 4141_mc.ext.ini
Initial [67ec86b]

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.

[mc-butler]

Changed by andrew_b (@aborodin) on Sep 25, 2022 at 11:54 UTC (comment 6)

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

[mc-butler]

Changed by andrew_b (@aborodin) on Sep 25, 2022 at 11:56 UTC (comment 7)

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

Merged to master: [3a3811c].

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

[mc-butler]

Changed by andrew_b (@aborodin) on Sep 25, 2022 at 12:02 UTC (comment 8)

• Status changed from testing to closed