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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
