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

Previous Next

Full log

Message #36 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mike Kupfer <m.kupfer <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Cc: Bill Wohler <wohler <at> newt.com>
Subject: bug#21650: fix should be underneath MH-E
Date: Mon, 01 Feb 2016 10:53:34 -0800

After some discussion with Bill Wohler, I've looked more carefully at
the problem, paying more attention to the overall system design and
layering.

MH-E uses the MIME (mm) libraries to render emails.  There is a variable
mm-inline-text-html-with-image which, according to the documentation,
should be sufficient to disable downloading of images.

  mm-inline-text-html-with-images is a variable defined in `mm-decode.el'.
  Its value is nil
  
  Documentation:
  If non-nil, Gnus will allow retrieving images in HTML contents with
  the <img> tags.  It has no effect on Emacs/w3.  See also the
  documentation for the `mm-w3m-safe-url-regexp' variable.

Unfortunately, shr does not honor mm-inline-text-html-with-images.
Instead, it uses #'gnus-blocked-images as its control (see #'mm-shr).

MH-E could temporarily rebind gnus-blocked-images before calling
#'mm-display-part.  But really, that's a hack to work around the fact
that the documented mm API doesn't work.

For email, it appears that a simple binary control is all that's needed
(either fetch remote images or not).  So it seems like it would be
straightforward for #'mm-shr to use mm-inline-text-html-with-images, and
for Gnus to set mm-inline-text-html-with-images as needed.

But for newsgroups, it looks like finer control is desired.  So I don't
know what the fix should look like.  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.

mike

Previous Next

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