RFC: Make ~/.mailcap override other settings

RFC: Make ~/.mailcap override other settings

[Lars Ingebrigtsen]

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[T.V Raman]

Lars Ingebrigtsen <larsi@gnus.org> 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?

-- 

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

[Mark Oteiza]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

Yikes, this does sound bizarre.

> 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?

+1.  Makes sense to me to have rule precedence follow the usual user-
then system- specific config convention.  The RFC[0] doesn't seem to say
anything about it and (as an example) it looks like that's how (neo)mutt
has done it [1].

[0] https://tools.ietf.org/html/rfc1524
[1] https://raw.githubusercontent.com/neomutt/neomutt/92914f28/rfc1524.c

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

[joakim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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?

I feel like I'm having trouble with this every time I want to view an
attachment, so FWIW, I'm for change in this area.

-- 
Joakim Verona
joakim@verona.se

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

[Lars Ingebrigtsen]

raman@google.com (T.V Raman) writes:

> 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?

No, they're not part of the mailcap system.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 12 Apr 2018 23:22:24 +0200
> 
> 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?

I'm okay with that change, provided that we leave some "fire escape"
for users who will want the old behavior.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm okay with that change, provided that we leave some "fire escape"
> for users who will want the old behavior.

Great!  I've had a look at the code, and it looks like it should be
pretty easy to make this a toggle (i.e., I don't have to alter any data
structures, I just have to add a new selection algorithm (that may be
switched off)).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Ok, that was even easier than I thought it would be, because the parser
already parsed everything in the logical order, so all I had to do was
disable a `sort'.

I've now pushed to master; let me know if you see any problems in this
area...  But I would guess that's pretty unlikely.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ok, that was even easier than I thought it would be, because the parser
> already parsed everything in the logical order, so all I had to do was
> disable a `sort'.

Hm...  I think it needs some further slight changes to make the Emacs
choices (for instance doc-view for PDF take precedence over
/etc/mailcap) in the new sorting method.  I'll tweak it a bit...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no