[Pkg-mc-devel] Bug#665763: Bug#665763: [mc] replace hardcoded applications in mc.ext with run-mailcap

[Mate Miklos]

Hi,

> in principle I perfectly agree to your position to use mailcaps.
> 
> On Sun, Mar 25, 2012 at 08:43:04PM +0200, Mate Miklos wrote:
> > Several applications are hardcoded into the default mc.ext, which could
> > be better handled by run-mailcap. Most of the hardcoded ones are not
> > installed by default, and/or have superior alternatives. Examples: the
> > entire sound section (eg. mpg123, ogg123),
> 
> ACK.
> 
> > mplayer for all videos (not even available in debian),
> 
> Well, mplayer is in Debian since a long time (fortunately).

I always installed it from debian-multimedia or from source, so I didn't 
notice this. Thanks for the tip.

> 
> > gv for postscript (evince and okular could handle it via see %f),
> 
> Here we now are starting to face a problem.  Evince maintainers silently
> decided to drop mime support.  You might like to read #658139 which has
> some frustrating mail exchange also on debian-devel.  So in this respect
> the complete trust on mailcap has some unfortunate cooincicence and this
> needs to be handled with a grian of salt.  Perhaps the Debian
> alternatives system might provide some better solution or MC should
> perhaps find a way to fallback if the expected application is not
> installed on the system.

#658139 seems to be an other incarnation of #497779. run-mailcap really needs 
some overhaul (and a proper fix for the really annoying bug #355627 ). Once I 
thought of rewriting it, but had no time.

My problems with the alternatives system is that it's a PITA to configure if 
you don't know about galternatives (maybe it should be installed by default), 
and it's system-wide (~/.mailcap is very useful).

> 
> > abiword and
> > gnumeric (most people use libreoffice instead).
> 
> I admit that these choices are a bit outdated these days.
> 
> > In fact, the entire mc.ext for finding suitable applications for opening
> > files is wrong, it should be "see %f" blindly for *everything* that has
> > X bit unset and try running the executable ones (too bad matching
> > permissions is impossible, so this cannot be implemened right now).
> 
> So I perfectly agree with the "see %f" approach but unfortunately bug
> #658139 makes this a bit questionable for the time beeing.
> 
> > Also worth noting is that determining file types based on filenames is
> > totally wrong, but this mistake is so prevalent, that fighting against
> > is is futile.
> 
> Fully ACK.  I guess mc has taken over this habit from Norton Commander
> and there are OSes out there that are following this wrong approach but
> under Linux we should rather use more robust mechanisms.  This should
> be reported upstream.

I think it's a classic case of worse is better. Theoretically file names have 
no connection with the type of the file contents, but most applications use so 
called 'extensions' to designate files (ms-dos rulez), so in most cases the 
filename suffixes are usable for type detection. Proper detection would need a 
*perfect* libmagic utility, but until someone creates sentinent AI it's next 
to impossible (and after that we will have much bigger problems).

MM