On Wed, 03 Feb 2016 19:58:46 -0800, Mike Kupfer wrote: > Bill Wohler wrote: >> Katsumi Yamaoka wrote: >>> My solution is below. Tested briefly. This patch moves the >>> binding of shr-inhibit-images and shr-blocked-images to Gnus >>> from mm. So, MH-E has to do a similar thing. >> >> I disagree. This only works for shr and defeats encapsulation. > I think what makes this a non-trivial problem is wanting more > flexibility than just a binary yes-no decision, which is what > mm-inline-text-html-with-images currently provides. That's why > gnus-blocked-images is a regexp (or a function that returns a regexp). > Could mm-inline-text-html-with-images be generalized to be more like > gnus-blocked-images? (For example, nil means don't retrieve anything, t > means retrieve everything, a string would be a regexp of what URLs will > be retrieved.) Then shr could use mm-inline-text-html-with-images > instead of shr-blocked-images, and MH-E users would have a single knob > that could control any of the different rendering back-ends. Ok, I was too near-sighted yesterday. Here is a second try: Implement the new user options in mm: `mm-html-inhibit-images' --- boolean Non-nil means inhibit displaying of images inline in the article body. The default is t. `mm-html-blocked-images' --- regexp or nil Regexp matching image URLs to be blocked. The default is "". Make `mm-inline-text-html-with-images' an obsolete variable alias for `mm-html-inhibit-images'. How Gnus does when calling an mm function: (defun gnus-function () (let ((mm-html-inhibit-images gnus-inhibit-images) (mm-html-blocked-images (with-current-buffer gnus-summary-buffer (gnus-blocked-images)))) (mm-function))) MH-E doesn't have to do like this if there's no need to have options like `mh-inhibit-images'. That's all. Is this the right approach? In Gnus, shr and gnus-html are controlled by both inhibit-images and blocked-images, and w3m is controlled by only inhibit-images. MH-E doesn't use gnus-html.el, does it? As for mm-shr, it would have to be changed into: