On Sat, 05 Dec 2009 15:10:18 -0800, Alexander Botero-Lowry <alex.boterolowry@gmail.com> wrote: > Carl mentioned that he saw some nasty performance issues with threads > that had a lot of HTML messages in them. > > If you are experiencing this problem, would you mind trying some > alternative mm-text-html-renderer setting: > > http://mh-e.sourceforge.net/manual/html/HTML.html > > Also, if you have elinks, I recommend my custom renderer: > > (require 'mm-view) > (add-to-list 'mm-text-html-renderer-alist > '(elinks mm-inline-render-with-stdin nil "elinks" "-force-html" "-dump")) > (setq mm-text-html-renderer 'elinks) Hi Alex, I'm sorry, but the delays got in my way so much this morning that I reverted the patch before even attempting the alternate renderer. Part of my annoyance may have been due to a distinct bug. There was definitely one instance where I was seeing a big delay when trying to display a tiny thread (about 13 messages) none of which were HTML. I reverted the HTML-rendering patch and saw the delay go away, but I also put the patch back and didn't see the problem come back. So that problem might have been form something else. But when I looked at the patch and saw that it was doing this: - (let ((filename (notmuch-show-get-filename))) - (with-temp-buffer - (insert-file-contents filename nil nil nil t) for every file, (regardless of it being HTML or not), I was convinced that there's got to be a better way. Notmuch has already passed the entire thread through GMime, so we really don't want to do a second pass of all of the raw message content through an emacs-lisp MIME parser as well. Instead, let's find a way to just get the information from GMime to be cheaply available for emacs to look at (without loading all of the original files). -Carl