[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Annoying HTML emails



At Sat, 30 Oct 2010 22:11:10 +0900,
Kazuhiro Ito wrote:
> 
> > A service I use (codebasehq) sends me messages that look like this:
> > 
> >   [1  <text/plain; utf-8 (quoted-printable)>]
> >   You need HTML email enabled to view this message.
> >   [2  <text/html; utf-8 (quoted-printable)>]
> >   ...interesting content here...
> > 
> > Infuriating, of course.  Is there any way I can make WL smart enough
> > to show me the HTML parts of these message by default?
> 
> As I wrote previously (*1), I write below code in my ~/.emacs.  This
> code makes text/html entity to be displayed when alternate text/plain
> entity does not exist.
> 
> (*1) http://thread.gmane.org/gmane.mail.wanderlust.general.japanese/8021/focus=8026
> 
> (eval-after-load "mime-view"
>   '(progn
>      (autoload 'mime-w3m-preview-text/html "mime-w3m")
>      (ctree-set-calist-strictly
>       'mime-preview-condition
>       '((type . text)
> 	(subtype . html)
> 	(body . visible)
> 	(body-presentation-method . mime-w3m-preview-text/html)))
>      (set-alist 'mime-view-type-subtype-score-alist
> 		'(text . html) 3)
>      (set-alist 'mime-view-type-subtype-score-alist
> 		'(text . plain) 4)))
> 

That's great... but shouldn't it be built-in functionality when we
enable mime-w3m, or at least selectable via a customize option?

> And, I tried writing a code to make the score of garbage text/plain
> part lower.

After suitable tweaks to your mime-entity-text/plain-score, worked
great; thanks!  Same question as above... shouldn't at least part of
this be built in to WL/SEMI?  I did a quick comparison to see what you
had actually changed in mime-display-multipart/alternative, and it
seems you just added this simple bit that allows one to specify a
function with which to score a MIME part.  

> 				  (when (functionp score)
> 				    (setq score (funcall score child)))


At the very least, it seems like any function as big as the standard
mime-display-multipart/alternative should contain such hooks so we
don't have to duplicate the code.  Thoughts?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com