David, This patch doesn?t allow users to have their own settings for shr-{inhibit,block}-images, since it forces these values to nil (via the corresponding gnus variables).
(For those looking to follow the code, here?s the call path: notmuch-show-mm-display-part-inline -> mm-display-part -> mm-display-inline -> (via lookup table) mm-inline-text-html -> (via LUT) mm-shr The last function is where this objectionable rebinding happens) Would a better approach be: - clone the mm-shr function, replacing the vile gnus-specific code with something functionally similar that takes the values from notmuch-foo variables instead - add '(notmuch-shr . notmuch-mm-shr) to the mm-text-html-renderer-alist variable - tell notmuch users to customize mm-text-html-renderer to 'notmuch-shr if they want to use this renderer The default values of the notmuch-{inhibit,block}-images variables should prevent network requests for images being made by default* ? your proposed nil/nil values don?t do this, AFAICT. Not doing network requests for HTML email has been Spam Mitigation/Identity Protection 101 for a long time;** notmuch?s default behavior in this area has always bothered me. (Also, while we are on the subject of wonky defaults, why is notmuch-show-all-multipart/alternative-parts set to t by default? This is certainly not the best setting.) FWIW, the patch does seem to allow using shr as the HTML renderer, but for the reasons expressed I don?t think it solves the broader problem. Aaron * I think that inhibit -> nil, block -> ".*" should achieve this, but I?m not sure/haven?t tested ** For example, Gmail makes you click a link at the top of an email before it will load any network images contained therein. -- Aaron Ecay