Re: RFC: Make ~/.mailcap override other settings

[T.V Raman]

Lars Ingebrigtsen <address@hidden> writes:

Simplifying these as you suggest would be a good thing. 

Looking at my .custom file, I also have things like 
mm-text-html-renderer and associated content-type definitions going back
the days of emacs/w3  -- defined in mm-decode.el -- do those need to be
reconciled as well?
to  > Since, well, forever, Emacs has had several sources for information
> about how to display files, like /etc/mailcap, ~/.mailcap and the
> `mailcap-mime-data' variable.
>
> But Emacs' handling of priorities here has never felt quite right, and
> they have historical reasons: In olden days, some distributions put a
> copy of /etc/mailcap into ~/.mailcap, so you didn't really know what the
> system preferences were and what the user's preferences were.
>
> So mailcap.el used the following precedence algorithm:
>
> 1) If it's in `mailcap-mime-data', use that.
>
> 2) If a specific type, say, "image/gif" is in both /etc/mailcap and
> ~/.mailcap, make the ~/.mailcap version win.
>
> 3) If we have less specific types covering the same type, make the most
> specific win.  So if /etc/mailcap has "image/gif; xv" and ~/.mailcap has
> "image/*; feh", then "image/gif" wins because it's more specific.
>
> I don't really think this ever made much sense.  I think if the user has
> put "image/*; feh" into ~/.mailcap, then that should win.
>
> So I propose to make this change on master.  It's backward-incompatible,
> but will lead to a lot less confusion in the years ahead.
>
> What do all y'all think?

--