Hi Bill,
I'm going through the list of old Emacs bugs in Debian.
On 2000-07-27 23:46 +0200, Bill Wohler wrote:
> Package: emacs20
> Version: 20.7-2
> Severity: normal
>
> In /etc/mailcap, the highest priority entries come first, followed
> by lower priority entries. The mailcap-parse-mailcaps parsing scheme
> doesn't seem to check for existing entries before adding entries to
> its internal cache (which should be updated if the mailcap files
> change, by the way).
>
> For example, my /etc/mailcap contains the following three entries
> for text/html:
>
> text/html; gnome-help-browser '%s';test=test "$DISPLAY" != ""
> text/html; /usr/bin/lynx -force_html '%s'; needsterminal;
> description=HTML Text; nametemplate=%s.html
> text/html; /usr/bin/lynx -dump -force_html '%s'; copiousoutput;
> description=HTML Text; nametemplate=%s.html
>
> When I use `b' in gnus to display a text/html body part, the last,
> lowest priority entry `lynx -dump -force_html %s' was used rather
> than `gnome-help-browser %s' at the top of the file. However, you
> don't have to run gnus to reproduce the problem; simply run
> (mailcap-mime-info "text/html").
This seems to be solved in emacs21 and later. I get these results:
(mailcap-mime-info "text/html") => "/usr/bin/sensible-browser '%s'"
(mailcap-mime-info "application/pdf") => "kpdf '%s'"
Both times this is the first entry in /etc/mailcap for the respective
MIME type, so I think we should close this bug. Do you agree?
Cheers,
Sven
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
