From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.bugs Subject: bug#21650: fix should be underneath MH-E Date: Thu, 04 Feb 2016 15:09:43 +0900 Organization: Emacsen advocacy group Message-ID: References: <6770.1454558326@allegro.localdomain> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1454566223 26617 80.91.229.3 (4 Feb 2016 06:10:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 06:10:23 +0000 (UTC) Cc: Lars Ingebrigtsen , 21650@debbugs.gnu.org, Bill Wohler To: Mike Kupfer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 04 07:10:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aRD7L-0004M2-61 for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 07:10:11 +0100 Original-Received: from localhost ([::1]:39804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRD7K-0004NK-GH for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 01:10:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRD7G-0004Lv-4m for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 01:10:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRD7C-0007fS-U8 for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 01:10:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRD7C-0007fN-QP for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 01:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRD7C-0005kR-MD for bug-gnu-emacs@gnu.org; Thu, 04 Feb 2016 01:10:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Katsumi Yamaoka Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Feb 2016 06:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21650 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 21650-submit@debbugs.gnu.org id=B21650.145456619622068 (code B ref 21650); Thu, 04 Feb 2016 06:10:02 +0000 Original-Received: (at 21650) by debbugs.gnu.org; 4 Feb 2016 06:09:56 +0000 Original-Received: from localhost ([127.0.0.1]:58819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRD76-0005js-85 for submit@debbugs.gnu.org; Thu, 04 Feb 2016 01:09:56 -0500 Original-Received: from mail-hampton.hostforweb.net ([205.234.186.191]:44282 helo=hampton.hostforweb.net) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRD74-0005jf-R9 for 21650@debbugs.gnu.org; Thu, 04 Feb 2016 01:09:55 -0500 Original-Received: from s70.gtokyofl21.vectant.ne.jp ([202.215.75.70]:62209 helo=localhost) by hampton.hostforweb.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aRD6v-002D6m-MU; Thu, 04 Feb 2016 00:09:47 -0600 X-Face: #kKnN,xUnmKia.'[pp`; Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu; B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (i686-pc-cygwin) Cancel-Lock: sha1:nm/kN4vCdmvRGEjTPYm02Kou91E= X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hampton.hostforweb.net X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Get-Message-Sender-Via: hampton.hostforweb.net: authenticated_id: yamaoka/from_h X-Authenticated-Sender: hampton.hostforweb.net: yamaoka@jpl.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112389 Archived-At: --=-=-= 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: --=-=-= Content-Type: text/x-patch Content-Disposition: inline --- mm-decode.el~ 2016-01-04 22:05:27.255542500 +0000 +++ mm-decode.el 2016-02-04 06:05:08.419602200 +0000 @@ -1846,11 +1846,5 @@ (buffer-string)))))) - shr-inhibit-images shr-blocked-images charset char) - (if (and (boundp 'gnus-summary-buffer) - (bufferp gnus-summary-buffer) - (buffer-name gnus-summary-buffer)) - (with-current-buffer gnus-summary-buffer - (setq shr-inhibit-images gnus-inhibit-images - shr-blocked-images (gnus-blocked-images))) - (setq shr-inhibit-images gnus-inhibit-images - shr-blocked-images (gnus-blocked-images))) + (shr-inhibit-images mm-html-inhibit-images) + (shr-blocked-images mm-html-blocked-images) + charset char) (unless handle --=-=-=--