Discussion:
RFC: Make ~/.mailcap override other settings
(too old to reply)
Lars Ingebrigtsen
2018-04-12 21:22:24 UTC
Permalink
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
T.V Raman
2018-04-13 02:38:56 UTC
Permalink
Lars Ingebrigtsen <***@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
Post by Lars Ingebrigtsen
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.
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?
--
Lars Ingebrigtsen
2018-04-13 11:49:52 UTC
Permalink
Post by T.V Raman
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
Mark Oteiza
2018-04-13 02:54:17 UTC
Permalink
Post by Lars Ingebrigtsen
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.
Post by Lars Ingebrigtsen
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
j***@verona.se
2018-04-13 08:21:46 UTC
Permalink
Post by 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.
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
***@verona.se
Eli Zaretskii
2018-04-13 14:00:03 UTC
Permalink
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.
Lars Ingebrigtsen
2018-04-13 15:40:54 UTC
Permalink
Post by Eli Zaretskii
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
Lars Ingebrigtsen
2018-04-13 17:11:08 UTC
Permalink
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
Lars Ingebrigtsen
2018-04-14 12:32:36 UTC
Permalink
Post by 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'.
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
Loading...