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

[Chris Gray]

On Mon, 19 Dec 2011 15:45:59 +0000, David Edmondson <dme at dme.org> wrote:
> Latest gnus provides a new HTML renderer entirely in lisp. It requires
> some minor but ugly scaffolding to allow use with notmuch.
> ---
> 
> This is pretty horrible, but works in the cases that I tested. It
> would be useful if a few other people could test. Note that `cid:'
> images included with a text/html part are not inserted in the correct
> place, but that also appears to be the case for gnus.
> 
> This should be tagged `notmuch::wip' in the new world order!
> 
>  emacs/notmuch-show.el |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 63b01e5..f52f233 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -320,6 +320,13 @@ message at DEPTH in the current thread."
>  	;; ange-ftp, which is reasonable to use here.
>  	(mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t)))))
>  
> +;; Nonsense required to have the new gnus `shr' HTML display code
> +;; work.
> +(defvar gnus-summary-buffer)
> +(defvar gnus-inhibit-images)

I believe that gnus-inhibit-images is defined in gnus-art.el.  Perhaps
that file should just be require'd rather than having this workaround.

> +(if (not (fboundp 'gnus-blocked-images))
> +    (defun gnus-blocked-images () nil))
> +
>  (defun notmuch-show-mm-display-part-inline (msg part nth content-type)
>    "Use the mm-decode/mm-view functions to display a part in the
>  current buffer, if possible."
> @@ -331,7 +338,12 @@ current buffer, if possible."
>  	    (let ((content (notmuch-show-get-bodypart-content msg part nth)))
>  	      (insert content)
>  	      (set-buffer display-buffer)
> -	      (mm-display-part handle)
> +
> +	      ;; Nonsense required to have the new gnus `shr' HTML
> +	      ;; display code work.
> +	      (let ((gnus-inhibit-images nil))
> +		(makunbound 'gnus-summary-buffer) ; Blech.

This is working around a bug in gnus.  I think the better solution would
be for gnus to fix the bug.  The following patch against gnus works for
me.  (I have tried submitting it to the gnus bug list, but have not been
able to check if it got through.)

Cheers,
Chris

commit 45e5a06ea63d8d9f9a962db7d739c7d7056ef712 (HEAD, refs/heads/master)
Author: Chris Gray <chrismgray at gmail.com>
Date:   Mon Dec 19 23:33:30 2011 -0700

    mm-decode.el (mm-shr): Added check to bufferp for gnus-summary-buffer
    
    If gnus-summary-buffer is a string, then (buffer-name
    gnus-summary-buffer) gives an error.

	Modified lisp/mm-decode.el
diff --git a/lisp/mm-decode.el b/lisp/mm-decode.el
index 44e2af5..7005dd7 100644
--- a/lisp/mm-decode.el
+++ b/lisp/mm-decode.el
@@ -1724,6 +1724,7 @@ If RECURSIVE, search recursively."
 				      (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