GNU bug report logs - #21650
24.5; mh-e keeps trying to open urls

Previous Next

Packages: emacs, mh-e;

Reported by: Simon Gerraty <sjg <at> juniper.net>

Date: Thu, 8 Oct 2015 18:43:01 UTC

Severity: normal

Found in version 24.5

Done: Mike Kupfer <m.kupfer <at> acm.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Glenn Morris <rgm <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 21650 <at> debbugs.gnu.org, Bill Wohler <wohler <at> newt.com>, Mike Kupfer <m.kupfer <at> acm.org>
Subject: bug#21650: fix should be underneath MH-E
Date: Tue, 02 Feb 2016 17:34:27 -0500
Katsumi Yamaoka wrote:

>>> But MIME libraries are documented as general-purpose, rather than
>>> private to Gnus. So this really ought to be resolved at the mm layer,
>>> rather than adding renderer-specific tweaks to MH-E.
>
>> Sounds absolutely right.
>
> The first step should be anyway to fix mh-cl-flet[1], recompile
> mh-e, and see how the behaviors change, I think.

I don't see how that's relevant to this issue.
mm-shr _always_ consults gnus-inhibit-images and gnus-blocked-images,
using them to override shr-inhibit-images and shr-blocked-images.
If mm-shr is supposed to be a general purpose facility for use by things
other than Gnus (?), this seems obviously wrong.
Surely Gnus should make whatever buffer-local shr-related settings it
needs in its Gnus buffers, and the MH-E folks can do the same, rather
than hard-coding Gnus-specific behavior in mm-shr?

(I'd actually say that the use of mh-cl-flet in mh-display-emphasis
seems like the wrong solution as well. MH-E should rather have asked
Gnus to provide an option so that article-emphasize can do what they
want.)




This bug report was last modified 8 years and 353 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.