[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Make ~/.mailcap override other settings
From: |
T.V Raman |
Subject: |
Re: RFC: Make ~/.mailcap override other settings |
Date: |
Thu, 12 Apr 2018 19:38:56 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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?
--