On Sun, Sep 02, 2007 at 10:08:08AM +0200, Thomas Roessler wrote: > > I'm in no way suggesting that the GUI interface should/could > > replace the terminal-oriented interface... just that both are > > often quite useful. I'm also aware that mutt can do formatting > > of rtf messages, but that requires that people actually SEND rtf > > mail, which pretty much no one ever does, so it's not a terribly > > useful feature. > > From a design perspective, that handler should actually be an > external filter. Conveniently enough, to illustrate the main point of my previous message, here's a fine example (from mutt-users) of an extremely commom case of e-mail where Mutt completely falls down, but is handled with ease by even the worst of the GUI mailers. The only way to handle this in Mutt is for the user to hack something together, or happen upon some kind soul who's already done it and made his hack publicly available. The case mentioned below is a common case of completely RFC-compliant e-mail which mutt *can not handle* in its current form without external hackery. This post even conveniently goes so far as to explain why the external viewer model is broken for this case... Mutt is dependent upon the existence of external programs that are friendly to Mutt's paradigm; but this paradigm is ancient, and newer programs don't adhere to it. As standards change, and new technologies arrive, one can imagine that there will continue to be new examples like this one, where the programs to handle the new technology are not Mutt/MIME-friendly. If Mutt's paradigm were changed to use modules (i.e. libraries), rather than external programs, there would likely be no problem at all, as in this case. On Fri, Aug 31, 2007 at 03:51:39PM -0700, Gary Johnson wrote: > On 2007-09-01, Kai Grossjohann <kai@xxxxxxxxxxxxxx> wrote: > > On Fri, Aug 31, 2007 at 10:14:36AM -0700, Gary Johnson wrote: > > > > > On 2007-08-31, Kai Grossjohann <kai@xxxxxxxxxxxxxx> wrote: > > > > On Thu, Aug 30, 2007 at 11:34:57PM -0500, Matt Okeson-Harlow wrote: > > > > > > > > > w3m can be compiled to display images in an xterm. > > > > > > > > Very well. But how do we convert a multipart/related message with > > > > text/html and image/foo parts into something that w3m can digest? > > > > > > Mutt doesn't know anything about HTML. Most browsers don't know > > > anything about cid references. So I think a solution could look > > > like this. [..write it yourself..] > > > > Yes, I agree, that would be a/the solution. I was merely hoping that > > somebody has done it already -- given that I think that this is a fairly > > common thing to want. But maybe I'm just weird and others don't > > need/want this. > > I didn't mean that to be dismissive. I would like such a feature > myself as I get e-mail every now and then from coworkers who > embed technical illustrations as JPGs in their HTML messages. But > I haven't found a ready-made solution yet, and I'm pretty busy > at the moment, so I thought I'd throw out the few ideas I had > in hopes of stimulating some discussion. If other people on this > list already know how to do parts of that solution, or have a > better solution in mind, we could have a solution up and running > before too long without any one person having to do very much work. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpEUMhGzkKYZ.pgp
Description: PGP signature