[RFC][PATCH] emacs: Provide scaffolding so that the new `shr' HTML renderer can run.

[Aaron Ecay]

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