[PATCH v3] emacs: show: possible w3m/invisibility workaround

[Austin Clements]

LGTM.  It's too bad the w3m-link-map logic in
mm-inline-text-html-render-with-w3m doesn't appear to work; it looks
like that would make links follow-able without completely taking over.

Quoth Mark Walters on Jan 13 at 12:43 pm:
> There is a bug in the current notmuch code with w3m and invisible
> parts. w3m sets a keymap, and if we have a hidden [text/html] point
> at the start of the following line still gets this w3m keymap which
> causes some strange effects. For example, RET gives an error "No URL
> at Point" rather than hiding the message, <down> goes to the next link
> rather than just down a line.
> 
> These keybinding are also inconvenient when the text/html part is
> displayed so we ask w3m not to install a keymap.
> 
> This is only likely to be a problem for emacs 23 as shr is preferred
> as html renderer on emacs 24 (although the user can set the renderer
> to w3m even on emacs 24).
> 
> This solution was suggested by Tomi Ollila <tomi.ollila at iki.fi>
> ---
> 
> On irc Tomi found the correct way of stopping w3m setting a keymap:
> there is a variable mm-inline-text-html-with-w3m-keymap which can be
> set to nil to tell w3m not to set a keymap.
> 
> I think this is the best solution to this bug for 0.15. My view is
> that this is correct anyway: w3m does render quickly and nicely (and
> will probably be my default renderer from now on) and with this patch
> the keybinding problems are the normal notmuch bindings.
> 
> Jani pointed out that in the new invisibility setup all text/html
> parts are rendered (invisibly) when notmuch-show runs. We may want to
> allow the user to supress this: in fact they can by setting
> mm-text-html-renderer to nil but we may want to allow the suppression
> without affecting gnus etc, or we may want to link this option into
> the notmuch-show customization, or maybe just mention in NEWS.

Could we make it simply render parts on demand when/if they become
visible?  There would be no loss of functionality and things would be
faster overall.

> Any such fix is a obviously a separate patch.
> 
> Best wishes
> 
> Mark
> 
> 
> 
>  emacs/notmuch-show.el |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 5751d98..1864dd1 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -818,6 +818,16 @@ message at DEPTH in the current thread."
>  (defun notmuch-show-insert-part-inline-patch-fake-part (msg part content-type nth depth declared-type)
>    (notmuch-show-insert-part-*/* msg part "text/x-diff" nth depth "inline patch"))
>  
> +(defun notmuch-show-insert-part-text/html (msg part content-type nth depth declared-type)
> +  ;; text/html handler to work around bugs in renderers and our
> +  ;; invisibile parts code. In particular w3m sets up a keymap which
> +  ;; "leaks" outside the invisible region and causes strange effects
> +  ;; in notmuch. We set mm-inline-text-html-with-w3m-keymap to nil to
> +  ;; tell w3m not to set a keymap (so the normal notmuch-show-mode-map
> +  ;; remains).
> +  (let ((mm-inline-text-html-with-w3m-keymap nil))
> +    (notmuch-show-insert-part-*/* msg part content-type nth depth declared-type)))
> +
>  (defun notmuch-show-insert-part-*/* (msg part content-type nth depth declared-type)
>    ;; This handler _must_ succeed - it is the handler of last resort.
>    (notmuch-show-insert-part-header nth content-type declared-type (plist-get part :filename))