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 debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org