[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WL displays only header ... no MIME buttons or content (was: Forward: Opinion Today: The Deafness Before the Storm)
At Sun, 07 Oct 2012 19:51:34 +0200,
David Maus wrote:
>
> At Sun, 23 Sep 2012 20:07:08 -0400,
> Peter Davis wrote:
> >
> > At Sun, 23 Sep 2012 20:00:05 -0400,
> > Peter Davis wrote:
> > >
> > > At Sun, 23 Sep 2012 10:35:45 +0200,
> > > David Maus wrote:
> > > >
> > > > [1 <text/plain; US-ASCII (quoted-printable)>]
> > > > At Thu, 20 Sep 2012 16:39:13 -0400,
> > > > Peter Davis wrote:
> > > > >
> > > > > At Thu, 20 Sep 2012 14:02:17 -0400,
> > > > > Peter Davis wrote:
> > > > > >
> > > > > >
> > > > > > So, I'm wrestling with the fact that some HTML messages (and multipart
> > > > > > messages with HTML parts) display (via w3m) and some don't. Is there any
> > > > > > way to trouble-shoot this further?
> > > > >
> > > > > To follow up on my own post here, some further testing suggests that all
> > > > > of the cases in which WL fails to display the HTML are using charset
> > > > > UTF-8, either 7bit or quoted printable.
> > > > >
> > > > > Unfortunately, there are some cases in which UTF-8 works just fine, so
> > > > > that's not the culprit by itself. But from a few samples, it seems that
> > > > > iso-8859-1, us-ascii and windows-1252 all display just fine.
> > > > >
> > > > > Still trying to figure out what's going on here. One strange thing is
> > > > > that I get lots of email updates from the New York Times site, and you
> > > > > would think they always use the same mail parameters. Yet some of these
> > > > > display and others don't.
> > > >
> > > > From my understanding of SEMI the rendering method is selected based
> > > > on the MIME type (cf. `mime-preview-condition'). You could check the
> > > > value of `mime-preview-condition' if the HTML message is not rendered
> > > > with w3m.
> > > >
> > > > There should be a dispatch to `mime-w3m-preview-text/html' -- if it is
> > > > there instrument the function (C-M-x), reopen the message and step
> > > > through it.
> > > >
> > >
> > > Well, I no sooner wrote my previous message then WL decided to let me
> > > view the thread after all. I think I just did 'p' and then 'n' to get
> > > back to the first message in the thread, and suddenly I could see the
> > > thread in the Summary window.
> >
> > Ok, I sent a reply to David's message a few minutes ago from Mutt, but
> > apparently that didn't go through. This one, which retracts the
> > complaint about the thread not expanding in WL, did.
> >
> > Anyway, David, I did examine mime-preview-condition. It looked like
> > reasonable code that would conditionally handle various MIME types and
> > subtypes, though I don't really know enough lisp to know much about
> > it.
> >
>
> It's a tree that is used to find the function that handles a
> particular MIME media type. Look for an entry for the type `text',
> e.g. here I have:
>
> ,----[ C-h v mime-preview-condition RET
> | ...
> | (text subtype
> | (plain body
> | (visible body-presentation-method
> | (wl-mime-display-text/plain major-mode
> | (wl-original-message-mode))))
> | (html body
> | (visible body-presentation-method
> | (mime-w3m-preview-text/html)))
> | (t body
> | (visible body-presentation-method
> | (mime-display-text/plain)))
> | (richtext body
> | (visible body-presentation-method
> | (mime-display-text/richtext)))
> | (enriched body
> | (visible body-presentation-method
> | (mime-display-text/enriched))))
> | ...
> `----
>
> As you can see in my case SEMI will use `mime-w3m-preview-text/html'
> to present text/html entities.
>
> Is there an entry for text/html if the HTML entity is /not/
> rendered?
My code, at least for "text" type, looks like what you excerpted
above. I'm not sure what to look for if HTML is /not/ rendered. In any
case, I'd prefer to have the HTML, if present, rendered through w3m.
>
> C-M-x refers to Emacs' debugger, edbug
>
> http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/edebug.html
>
> C-h f mime-w3m-preview-text/html RET
>
> to locate the function and then
>
> C-u C-M-x ;; Control and Meta and x at the same time
>
> to enable the debugger for this function. Next time this function is
> called the debugger takes control and lets you step through the
> function with SPC.
I'll try this when I have a chance to experiment. I'll report my
findings here.
Thank you!
-pd