HTML recognition

HTML recognition

[Harry Putnam]

With pgnus abiltiy  to display html with little or no fanfare (w3), I
find that I'd like to have some way to recognize a message as being in
html format before opening it.  Most often (by far) I don't want to
see the message at all.  At least not in News or mailing list
messages.

It is very rare in such places, for the html messages to be something
I want to read, so would prefer to just hit "d" and move on.  I prefer
having the choice, (hitting d or not) to just filtering out html
messages altogether.

Is this just a matter of fiddling the Header variables so something is
displayed in the normal view that indicates an html message?

If so, how is this done?

Re: HTML recognition

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> With pgnus abiltiy  to display html with little or no fanfare (w3), I
> find that I'd like to have some way to recognize a message as being in
> html format before opening it.  Most often (by far) I don't want to
> see the message at all.  At least not in News or mailing list
> messages.

You could add Content-type to gnus-extra-headers and then include
something in the summary lines based on that header.  Hm.  I guess
this would amount to a bit of programming -- you would need a function
which, given the header, generates an informative character or two,
and then you would have to add that function to the summary line
format.

I'm not sure that it will work, though.  Hm.  Normally, Gnus just
reads the overview files when entering a group, right?  And of course,
Content-type isn't in the overview, so Gnus doesn't have the
information.  And fetching the header of all messages in the group
will take a long time.

Hm.

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Alan Shutko]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I'm not sure that it will work, though.  Hm.  Normally, Gnus just
> reads the overview files when entering a group, right?  And of course,
> Content-type isn't in the overview, so Gnus doesn't have the
> information.

Add it to 


       A related variable is `nnmail-extra-headers', which controls
    when to include extra headers when generating overview (NOV)
    files.  If you have old overview files, you should regenerate them
    after changing this variable.


-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
You're definitely on their list.  The question to ask next is what list it is.

Re: HTML recognition

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > With pgnus abiltiy  to display html with little or no fanfare (w3), I
> > find that I'd like to have some way to recognize a message as being in
> > html format before opening it.  Most often (by far) I don't want to
> > see the message at all.  At least not in News or mailing list
> > messages.
> 
> You could add Content-type to gnus-extra-headers and then include
> something in the summary lines based on that header.  Hm.  I guess
> this would amount to a bit of programming -- you would need a function
> which, given the header, generates an informative character or two,
> and then you would have to add that function to the summary line
> format.
> 
> I'm not sure that it will work, though.  Hm.  Normally, Gnus just
> reads the overview files when entering a group, right?  And of course,
> Content-type isn't in the overview, so Gnus doesn't have the
> information.  And fetching the header of all messages in the group
> will take a long time.

This is starting to sound like more work and skill than I have,
fortunately it isn't a burning issue.  But since we've broached the
subject of .overview files, I'm curious what certain portions mean.
Take the .overview entry to your reply to my query:
(filled for viewing)

  2292 Re: HTML recognition Kai.Grossjohann@CS.Uni-Dortmund.DE 
  (Kai Großjohann) 10 Oct 1999 03:22:03 +0200
  <vafu2o0row4.fsf@lucy.cs.uni-dortmund.de>
  <m3g0zkt64y.fsf@satellite.local.lan> 1015 27 Xref: satellite.local.lan
  ding:2292 To: ding@gnus.org
  
All entries are pretty self explanatory except the "1015 27" just
before the Xref entry.

Re: HTML recognition

[Russ Allbery]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

Harry Putnam <reader@newsguy.com> writes:

>   2292 Re: HTML recognition Kai.Grossjohann@CS.Uni-Dortmund.DE 
>   (Kai Großjohann) 10 Oct 1999 03:22:03 +0200
>   <vafu2o0row4.fsf@lucy.cs.uni-dortmund.de>
>   <m3g0zkt64y.fsf@satellite.local.lan> 1015 27 Xref: satellite.local.lan
>   ding:2292 To: ding@gnus.org
  
> All entries are pretty self explanatory except the "1015 27" just before
> the Xref entry.

Bytes in the article, lines in the article.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: HTML recognition

[Lloyd Zusman]

Harry Putnam <reader@newsguy.com> writes:

> [ ... ]
> 
> This is starting to sound like more work and skill than I have,
> fortunately it isn't a burning issue.  But since we've broached the
> subject of .overview files, I'm curious what certain portions mean.
> Take the .overview entry to your reply to my query:
> (filled for viewing)
> 
>   2292 Re: HTML recognition Kai.Grossjohann@CS.Uni-Dortmund.DE 
>   (Kai Großjohann) 10 Oct 1999 03:22:03 +0200
>   <vafu2o0row4.fsf@lucy.cs.uni-dortmund.de>
>   <m3g0zkt64y.fsf@satellite.local.lan> 1015 27 Xref: satellite.local.lan
>   ding:2292 To: ding@gnus.org
>   
> All entries are pretty self explanatory except the "1015 27" just
> before the Xref entry.

1015 is the number of characters in the article.  27 is the number
of lines.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: HTML recognition

[Kai Großjohann]

Alan Shutko <ats@acm.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > I'm not sure that it will work, though.  Hm.  Normally, Gnus just
> > reads the overview files when entering a group, right?  And of course,
> > Content-type isn't in the overview, so Gnus doesn't have the
> > information.
> 
> Add it to [...] nnmail-extra-headers [...]

Will that work for news?  The original poster was talking of news, IIRC.

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Alan Shutko <ats@acm.org> writes:
> 
> > Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> > 
> > > I'm not sure that it will work, though.  Hm.  Normally, Gnus just
> > > reads the overview files when entering a group, right?  And of course,
> > > Content-type isn't in the overview, so Gnus doesn't have the
> > > information.
> > 
> > Add it to [...] nnmail-extra-headers [...]
> 
> Will that work for news?  The original poster was talking of news, IIRC.

I did say News and mailing lists: (From origingal post)
". . . . . . . . At least not in News or mailing list messages."


Yes, this adds the info to .overview alright... (in nnmail) now to get
it to appear in the headers that are displayed in the short view...

( and some remedy for news)

But also a problem arises in this way:

Pgnus displays only this "Content-Type": 
multipart/alternative; boundary="=-=-="

At least that is all that appears in the long view of headers with a
specific html message in focus.  Now pressing `C-u g' displays two
messages.  One in plain text, one in html.  And another Content-Type
header "Content-Type: text/html" appears before the html message.

The last header is the one I want to display, but it does'nt seem to
be available until `C-u g' ing the message.

Haven't been able to figure out how to make netscape send those nasty
text and html messages to myself, and I haven't gotten an html message
recently to see what it looks like before gnus gets hold of it.

But it seems that all "Content-Type" headers should be visible in the
long view of headers, without C-u g 'ing.

Re: HTML recognition

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> At least that is all that appears in the long view of headers with a
> specific html message in focus.  Now pressing `C-u g' displays two
> messages.  One in plain text, one in html.  And another Content-Type
> header "Content-Type: text/html" appears before the html message.
> 
> The last header is the one I want to display, but it does'nt seem to
> be available until `C-u g' ing the message.

That's because it is part of the _body_ of the message.  Everything
after the first empty line is the body of the message, even if it
looks like a header.  This is unfortunate for your application, of
course.  The Content-type `multipart/alternative' doesn't tell you
much; could be a choice between image/gif and image/jpeg, as well...

When you do `C-u g' you see the article as Gnus received it, ie you
don't need an extra tool to show the articles `before Gnus gets them'.

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> That's because it is part of the _body_ of the message.  Everything
> after the first empty line is the body of the message, even if it
> looks like a header.  This is unfortunate for your application, of
> course.  The Content-type `multipart/alternative' doesn't tell you
> much; could be a choice between image/gif and image/jpeg, as well...

Err . . yes of course it wouldn't be a header if not in the "head".
Poor terminology here.

I've managed a way to get a simple header (in the "head" he he) into
mail containing html messages by using a home-grown procmail technique
like so:

 :0 HB
 * ^Content-Type: text/html
   {
 	:0
 	| formail -I "X-HTML: HTML Message" >> /var/spool/mail/reader
         
    }
(scans the head and body for string)

Not well tested and probably introduces all sorts or horrible locking
problems.  But I'll work up a better one later that writes to
mailspool with out the redirect.  Now with a header like this:
X-HTML: HTML Message

Adding that to extra headers for nnmail at least is a start.

It still seems fairly complicated to get the "Summary Format" %u
designator to do something useful, like stick "HTML" in the summary
format.

Re: HTML recognition

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> It still seems fairly complicated to get the "Summary Format" %u
> designator to do something useful, like stick "HTML" in the summary
> format.

I think the most complicated part of it is to get the value of the
header from the internal structure.  Lessee, I think I did something
like this for todo-gnus.el...  Right, I found it:

(defun gnus-user-format-function-T (head)
  (let* ((extra-headers (mail-header-extra head)))
    (cdr (assoc 'X-Todo-Priority extra-headers))))

This extracts the header X-Todo-Priority, but it ought to be simple to
change... 

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[David S. Goldberg]

I think that to do what you want is probably too hard.  The html can
be buried deep in a nested MIME multipart such that its existence is
not indicated in any header.  IOW Gnus has to open the article and
find the html before it can realize the html is there.  There might be 
some cases where the content-type of the entire article is text/html,
but I find those to be rare except for the idio^H^H^H^Hpeople here at
work who insist on setting up netscape to send text/html no matter
what.

If you use procmail, you might be able to intercept text/html directed
at your mailing list groups ahead of time and either delete the
messages or otherwise set up some scheme by which Gnus could warn you,
but I'm not sure its worth the effort.  It also wouldn't help you in
the case of nntp groups.  I pretty much agree with what you want to
do, and actually looked into it a while back.  After realizing the
above problems, I ended up just doing

(setq mm-automatic-display (delete "text/html" mm-automatic-display))

in my .gnus so that w3 isn't called automatically.  Unfortunately the
raw html is inlined, but at that point I can easily decide whether to
K v the part to have w3 process or just ignore it.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: HTML recognition

[Toby Speight]

David> David S. Goldberg <URL:mailto:dsg@mitre.org>

0> In article <m1biu4engke.fsf@blackbird.mitre.org>, David wrote:

David> After realizing the above problems, I ended up just doing
David>
David> (setq mm-automatic-display (delete "text/html" mm-automatic-display))
David>
David> in my .gnus so that w3 isn't called automatically.

I've had great success using
  (setq mm-discouraged-alternatives '("text/html" "text/richtext"))
because just about all HTML mails include a plaintext alternative
(which raises the question, why bother with the HTML?).

The only time this has failed was when the alternatives were text/plain
and multipart/related - the HTML was inside the Related (the idiot had
included an image - presumably a company logo - in his/her spam).

Re: HTML recognition

[David S. Goldberg]

> I've had great success using
>   (setq mm-discouraged-alternatives '("text/html" "text/richtext"))
> because just about all HTML mails include a plaintext alternative
> (which raises the question, why bother with the HTML?).

I have that setting too, but I still get a lot of html mail that
doesn't have the text/plain alternative, or the html is an attachment
(we also have idio^H^H^H^Hpeople here who insist on sending the html
of web pages they've developed instead of providing a URL; worse some
people send msword attachments accompanied by an html conversion of
the document).  

Anyway, with my settings, I only have w3 process the html when I want
it so I'm reasonably happy with it.  If I could just find an easy way
of treating all html stuff as attachment instead of inline, I'd be
even happier.  Modifying mm-inlined-types isn't appealing since my
experience with regexps says that there's no reasonable regexp to
"match everything except html" and there's apparently no analog to
mm-attachment-override-types.  Hmm, maybe a defadvice to eliminate the
path to w3 in mm-inline-text...  Nah, I'm pretty sure I don't like
that approach.  I do get enough html mails that I want to process with
w3 and the hassle of turning off the advice, re-selecting the article
etc seems too much.  I can live with the raw html.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: HTML recognition

[Toby Speight]

David> David S. Goldberg <URL:mailto:dsg@mitre.org>

0> In article <m1b1zb2ndk0.fsf@blackbird.mitre.org>, David wrote:

David> ... there's apparently no analog to mm-attachment-override-types.

Perhaps there should be - are you volunteering?

Re: HTML recognition

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Dave Thomas <Dave@Thomases.com>  on Mon, 11 Oct 1999
| So maybe we should instead be looking for ways of handling it more
| gracefully, rather than trying to adopt a somewhat perverse elitist
| 'if it ain't 7-bit I ain't reading it' approach.

But... but I *LIKE* my elitist "if it ain't 7-bit I ain't reading it"
approach. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0d (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4Agj8gl+vIlSVSNkRAtouAJ9/aQ3u79oieD4au/KKdNbgN2E7aQCfWi24
o7ufv3172B2+X6oyCZAz324=
=yU+a
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: HTML recognition

[Toby Speight]

Dave> Dave Thomas <URL:mailto:Dave@Thomases.com>

0> In article <m2bta5apkg.fsf@fast.local.thomases.com>, Dave wrote:

Dave> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

>> (which raises the question, why bother with the HTML?).

Dave> You know, I dislike receiving HTML mail, because W3 doesn't
Dave> really do a great job of rendering it on my setup, and because
Dave> I'm slightly bitter that I don't have an easy way of creating
Dave> it.  However, I think that having some kind of markup in e-mail
Dave> is generally useful - it allows me greater expression, gives me
Dave> automatic word-wrap when needed, potentially lets me identify
Dave> quoted regions explicitly (rather than guessing), and generally
Dave> provides me with a better kind of communication medium than this
Dave> punched-card based metaphor we're using now.

Right.  But if it's used properly like this[1], then I can turn the
question around and ask, "If the content is so rich, is the plaintext
version acceptable?"

[1] It isn't, in the stuff I've received.  It's invariable TITLE-less,
    stuffed full of FONT FACE crap, never a BLOCKQUOTE or OL when
    you'd expect one (from looking at the plaintext version), and
    sometimes even with a BR at the end of each line of text (leading
    to alternating long/short lines - Ugh!).


Dave> So maybe we should instead be looking for ways of handling it
Dave> more gracefully, rather than trying to adopt a somewhat perverse
Dave> elitist 'if it ain't 7-bit I ain't reading it' approach.

I wasn't trying to suggest that; sorry if it appeared that way.

Re: HTML recognition

[Jack Vinson]

>>>>> "HP" == Harry Putnam <reader@newsguy.com> writes:

HP> [...]  Most often (by far) I don't want to see the message at all.  At
HP> least not in News or mailing list messages.
[...]
HP> Is this just a matter of fiddling the Header variables so something is
HP> displayed in the normal view that indicates an html message?

I have been using the mm-discouraged-alternatives to get away from
text/html wherever possible, but there are the people who like to use HTML
only.  What I would really like, in combination with the discouraged
alternatives is a variable which tells gnus to ALWAYS buttonize certain
types.  If it is HTML that I actually want to read, I can just click on the
button and have it processed per mm-inline-media-tests (I hope).


-- 
Jack Vinson
Bart: I will not defame New Orleans.

Re: HTML recognition

[Russ Allbery]

Dave Thomas <Dave@Thomases.com> writes:

> If everyone could compose and read (say) rtf or html e-mail, then why
> shouldn't we use it?

Mostly because it's usually not worth it for the marginal additional
readability derived from real markup and it's presented as an all or
nothing endeavor (you either send all your mail in HTML or none of it).
The problem with both is that they have an entry cost; if you don't want
to write the markup or don't think your text will benefit from markup, but
you're writing in HTML, you *still* have to make some effort to ensure
that the HTML processing doesn't mangle it (escape <>&, tag paragraphs,
handle literal text and short lines, do something with quoting, etc.).
The common case is a message like this one, which really doesn't need any
markup at all.

HTML doesn't handle the common case well.

Plus, if one takes a step back and looks at the actual problem, one finds
that HTML is really a very bad markup language to use for the purpose.
It's ill-suited for Usenet or e-mail text, it's unnecessarily verbose,
it's complex to parse, it loses important information like sentence
boundaries gratuitously, and it's based on an underlying specification
system that's massive overkill for the problem.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: HTML recognition

[Kai Großjohann]

Jack Vinson <vinson@unagi.cis.upenn.edu> writes:

> [...] What I would really like, in combination with the discouraged
> alternatives is a variable which tells gnus to ALWAYS buttonize certain
> types. [...]

There is a variable mm-inline-media-tests.  And then there's
mm-inlined-types.  I'm not sure about the relation between these.

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Kai Großjohann]

HTML, when used judiciously, can surely be of benefit.  HTML, when
abused, is an abomination.  Even when HTML is used well, it is a
suboptimal choice for email markup.  But I think it is better to
implement a suboptimal choice well (as well as possible) than to use a
better choice which nobody else uses.

There are so many examples where the mediocre has won over the
superior that I'm not sure that it is worth the fight (in this case).
I think it's a lost cause.

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Russ Allbery]

Dave Thomas <Dave@Thomases.com> writes:
> Russ Allbery <rra@stanford.edu> writes:

>> The problem with both is that they have an entry cost; if you don't
>> want to write the markup or don't think your text will benefit from
>> markup, but you're writing in HTML, you *still* have to make some
>> effort to ensure that the HTML processing doesn't mangle it (escape
>> <>&, tag paragraphs, handle literal text and short lines, do something
>> with quoting, etc.).

> No, your MUA does all that for you. You just type.

As someone who's written a text to HTML converter, I wish it were that
easy, but it's not.  What do you do with something like:

 - First point.

 - Second point.

when you find it in the middle of the message?  How about:

    while (1) {
        fork();
    }

and how do you recognize something like that to mark it up correctly?
What do you do with nested quoting, which is a real bear in HTML?

If your MUA does all that for you, you end up with HTML of the sort that's
generated by Netscape or Microsoft's automated markup generators, which
frequently do horrid things to stuff like that and in general guess wrong
a lot.  That defeats the whole purpose of using markup, at least in my
opinion.

I've managed to write a text to HTML converter that gets things *I've*
written right about 99% of the time.  It botches horribly things written
by other people with slightly different writing styles.  I'm really
skeptical of the idea that it's possible to do significantly better.

I suppose you can dump the user into a WYSIWYG interface to compose their
e-mail, but I'd really rather not go there.

> Plain text word wrapping sucks, html does it, but at the expense of
> having to distinguish text *not* to be wrapped. Etc etc..

Actually, I'd say that plain text word wrapping works quite well.  We're
all using emacs, I presume.  emacs does a very good job at this.  I don't
even have to think about it.  Even if someone else uses substandard broken
software, emacs can generally do a decent job of fixing it.

And I've seen HTML word wrapping break badly.  It's an interesting
exercise to read a lot of the web with a decent font size (say 18pt or so)
and watch the text go off the side of the screen because people are
abusing tables and other similar constructs.

> I'm just saying that it's unfortunate that those in the van seem so
> wedded to TTY and Telex technologies, and often have a knee-jerk
> reaction against alternatives which, if widely employed, might actually
> make things better.

If you're a writer, or have read books on writing, you've probably heard
the tales of how, when submitting manuscripts for publication, you never
use proportional fonts and normal spacing.  You submit double-spaced
manuscripts in fixed-width fonts.  Why?  Because the editors read
manuscripts all day long, they've always read manuscripts like that, and
they like it that way.

To me, news and e-mail are tools.  The important part is the content; the
formatting is just a mechanism to get it to where I can read it.  I've
been reading it the same way for a very long time now and I'm used to
plain text with 70-76 column margins in a fixed-width font.  I've tweaked
my fonts from years of experience so that they're maximally readable with
a minimum of eye strain because I'm reading text on a computer screen for
twelve, fourteen, or more hours a day.

The flipside of "try it, it might improve things" is "why fix it when it's
not broken."

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: HTML recognition

[Russ Allbery]

Dave Thomas <Dave@Thomases.com> writes:

> LyX does stuff like this all the time. So do Netscape/Outlook mail
> composers. I don't see why you have to be hampered by a plain text input
> regime and heuristics when you're trying to move away from that into a
> world of logical markup.

But I'm not trying to make that move, because that world doesn't offer me
anything I care about *for news and e-mail*.  I'm not trying to deny other
people whatever freedom that they think they want; I'm trying to point out
that turning their e-mail to me into eye candy isn't going to communicate
any more efficiently.  Basically, I'm extremely skeptical of the idea that
such facilities will be used well.  They historically haven't been, and
word processors certainly largely aren't despite the fact that they're
applied to a problem domain better suited for this solution.

There are many features for me in communicating with people in plain
text.  It helps some in making people focus on what they're trying to say
rather than how they're trying to say it.

> I agree - but there's no need for automation. Type in code, highlight
> it, and say 'this is code' (just like you'd now type it in, select it
> and C-u 4 C-x TAB to offset it)

I don't want to do this.  There's no reason for it.  I *don't* use that
key combination to indent code; I just hit tab or the space bar a few
times.  The same way I intend a list.

I object to the general trend that says I should have to use more
keystrokes and memorize more commands to communicate my intention to
software.  I really don't want more buttons, commands, and key bindings
unless they either add functionality that I don't already have or are
absolutely necessary for some reason.  The purpose of software isn't to
impress me with the things it can do, but rather to get out of my way as
much as possible.  I already know how to make a list or type code.

> But... it wraps only during composition (see the other thread on hard
> vs. soft newlines. Rewrapping a message written by someone with a
> different width screen is hard - too much information is lost in plain
> text.

Again, I think emacs already does a perfectly reasonable job at this.

> Not mine - Addison Wesley asked for a 1.5\baselineskip galley set in
> Bookman.[1] In fact, most of what I've read suggests a good proportional
> font is more readable.

Fiction may be a different world than non-fiction here.  It wouldn't
surprise me; technical writing has a different publication process anyway.

> Just because it's not for you is no reason to deny it to others.

I'm not going to break into their homes and steal their HTML composers.
:)  I think that's a poor phrasing of the issue, since it implies that
what they're doing doesn't affect me.  It's not just that they want to use
it; they want to send it to me.  I don't see why I should have to run lynx
or some equivalent on my incoming mail just because people have some
aversion to using *stars* for bold.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: HTML recognition

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> HTML, when used judiciously, can surely be of benefit.  HTML, when
> abused, is an abomination.  Even when HTML is used well, it is a
> suboptimal choice for email markup.  But I think it is better to
> implement a suboptimal choice well (as well as possible) than to use a
> better choice which nobody else uses.
> 
> There are so many examples where the mediocre has won over the
> superior that I'm not sure that it is worth the fight (in this case).
> I think it's a lost cause.

In the original post that started this thread, my aim was only to have
an indicator in summary buffer to let me know a message contains html.

I only mentioned that in News and Mailing lists, most often the HTML
stuff is not something I want to read.  Usually it is a novice who may
not even know s/he is posting html.  (i.e.  not a message needing
urgent attention)

Since I am life long blue collar worker, all my family is too and
most of my friends who are now getting computers, likewise... This
makes a situation where my personal mail may well be HTML that I *do*
want to read (Even though I may prefer it wasn't in html), so not
interested in just ditching it altogether.  (It seems the blue collar
crowd really dig the trick windows html stuff.)

I have a cleaner recipe for procmail that will find "Content-Type:
html/text" anywhere in a message, and will add a header like:

X-HTML: HTML Message 

This header is not like the "Content-Type" header since it will always
be where headers are supposed to be.  The recipe will add the header
then send the message on to the normal spoolfile where gnus will find
it and split etc.


 :0HBfh
  * Content-Type: text/html
  | formail -I "X-HTML: HTML Message"

Kai, earlier in this thread has posted the function that will allow
using the "%u" specifier to show something in summary buffer to
indicate which messages have html in them.   Looks like it can be used
to find the added header and insert some Key letter or letters in
Summary buffer.  (Haven't tried it yet myself)

But would this not be a good thing?  You'd know *before* opening a
message and have the choice of moving on or opening with w3.

Re: HTML recognition

[Toby Speight]

Kai> Kai Großjohann <URL:mailto:Kai.Grossjohann@CS.Uni-Dortmund.DE>

0> In article <vafk8otlhr7.fsf@lucy.cs.uni-dortmund.de>, Kai wrote:

Kai> There is a variable mm-inline-media-tests.  And then there's
Kai> mm-inlined-types.  I'm not sure about the relation between these.

`mm-inline-media-tests' specifies what *can* be inlined.
`mm-inlined-types' specifies what *should* be inlined.
`mm-automatic-display' specifies what should be inlined *initially*.
`mm-attachment-override-types' controls *attachment* inlining.

For the poster who didn't want to see HTML by default (but still have
the button for an explicit choice to view it), try

  ;; untested
  (setq mm-automatic-display (delete "text/html" mm-automatic-display))

Does that do what you want?

Re: HTML recognition

[Kai Großjohann]

Harry Putnam <reader@newsguy.com> writes:

> But would this not be a good thing?  You'd know *before* opening a
> message and have the choice of moving on or opening with w3.

It's a good thing, but it requires procmail.  So I doubt that it would
be a good idea to include it as a standard Gnus behavior.

As far as I'm concerned, I don't mind waiting a few seconds for W3 to
render the HTML, and I'm happy that W3 pretty much hides the fact that
it's HTML.  (Except for the W3 startup time, that is.)

kai
-- 
Life is hard and then you die.

Re: HTML recognition

[Robert Bihlmeyer]

Hi,

>>>>> On 12 Oct 1999 10:40:58 +0100
>>>>> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> said:

 Toby> `mm-inline-media-tests' specifies what *can* be inlined.

... and *how* it is inlined.

(I actually think, that this is a non-intuitive overloading of the
variable. Either rename it, or split its functionality.)

 Toby> `mm-inlined-types' specifies what *should* be inlined.
 Toby> `mm-automatic-display' specifies what should be inlined *initially*.
 Toby> `mm-attachment-override-types' controls *attachment* inlining.

Thanks, Toby! This should probably go into the manual.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: HTML recognition

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > But would this not be a good thing?  You'd know *before* opening a
> > message and have the choice of moving on or opening with w3.
> 
> It's a good thing, but it requires procmail.  So I doubt that it would
> be a good idea to include it as a standard Gnus behavior.

Yes, wasn't suggesting it be incorporated into gnus.  Just an idea for
users.

> 
> As far as I'm concerned, I don't mind waiting a few seconds for W3 to
> render the HTML, and I'm happy that W3 pretty much hides the fact that
> it's HTML.  (Except for the W3 startup time, that is.)

That is a nice feature of gnus.  But that initial startup can be kind of
lengthy if it is a substantial message.  Any w3 rendering after the
first is much quicker and more tolerable.  

Re: HTML recognition

[Jack Vinson]

>>>>> "TS" == Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

TS> For the poster who didn't want to see HTML by default (but still have
TS> the button for an explicit choice to view it), try

TS>   ;; untested
TS>   (setq mm-automatic-display (delete "text/html" mm-automatic-display))

Unfortunately this gives me raw html for the person who sent me an
html-only message.  Does this have something to do with the fact that my
mm-inlined-types is the default:
        ("image/.*" "text/.*" "message/delivery-status" "message/rfc822")
and will automagically match "text/html"?  It is interesting that with that
match, it gives me generic text inlining rather than html.  (Because I have
removed the automatic-display of text/html.)

Hmm.  Even if I remove text/.* from mm-inlined-types, I get the raw text
instead of just a button.

-- 
Jack Vinson
Bart: All work and no play makes Bart a dull boy.

Re: HTML recognition

[David S. Goldberg]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

David> David S. Goldberg <URL:mailto:dsg@mitre.org>
0> In article <m1b1zb2ndk0.fsf@blackbird.mitre.org>, David wrote:

David> ... there's apparently no analog to
David> mm-attachment-override-types.

> Perhaps there should be - are you volunteering?

Sure, why not?  Sorry it took so long, but attached are patches to
gnus-art.el, mm-decode.el and a changelog entry that add a
mm-inline-override-types variable and use it.  Works for me anyway.

-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ChangeLog.patch --]
[-- Type: text/x-patch, Size: 514 bytes --]

--- /afs/rcf/user/dsg/elisp/gnus/lisp/ChangeLog.0.97	Wed Oct 20 14:36:12 1999
+++ /afs/rcf/user/dsg/elisp/gnus/lisp/ChangeLog	Wed Oct 20 14:36:12 1999
@@ -1,3 +1,11 @@
+1999-10-20  David S. Goldberg  <dsg@mitre.org>
+
+	* mm-decode.el mm-inline-override-types: New variable
+
+	* mm-decode.el (mm-inline-override-p): Use it
+
+	* gnus-art.el (gnus-mime-display-single): Then use that
+
 Mon Sep 27 15:18:05 1999  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>
 
 	* gnus.el: Pterodactyl Gnus v0.97 is released.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: gnus-art.el.patch --]
[-- Type: text/x-patch, Size: 540 bytes --]

--- /afs/rcf/user/dsg/elisp/gnus/lisp/gnus-art.el.0.97	Wed Oct 20 14:24:33 1999
+++ /afs/rcf/user/dsg/elisp/gnus/lisp/gnus-art.el	Wed Oct 20 14:24:33 1999
@@ -3132,7 +3132,8 @@
 		       (or (not (mm-handle-disposition handle))
 			   (equal (car (mm-handle-disposition handle))
 				  "inline")
-			   (mm-attachment-override-p handle)))
+			   (mm-attachment-override-p handle)
+			   (not (mm-inline-override-p handle))))
 		 (mm-automatic-display-p handle)
 		 (or (mm-inlined-p handle)
 		     (mm-automatic-external-display-p type)))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: mm-decode.el.patch --]
[-- Type: text/x-patch, Size: 1089 bytes --]

--- /afs/rcf/user/dsg/elisp/gnus/lisp/mm-decode.el.0.97	Wed Oct 20 14:23:51 1999
+++ /afs/rcf/user/dsg/elisp/gnus/lisp/mm-decode.el	Wed Oct 20 14:23:51 1999
@@ -142,6 +142,9 @@
 (defvar mm-attachment-override-types '("text/plain" "text/x-vcard")
   "Types that should have \"attachment\" ignored if they can be displayed inline.")
 
+(defvar mm-inline-override-types nil
+  "Types that should be treated as attachments even if they can be displayed inline.")
+
 (defvar mm-automatic-external-display nil
   "List of MIME type regexps that will be displayed externally automatically.")
 
@@ -491,6 +494,16 @@
       (while (setq ty (pop types))
 	(when (and (string-match ty type)
 		   (mm-inlinable-p handle))
+	  (throw 'found t))))))
+
+(defun mm-inline-override-p (handle)
+  "Say whether HANDLE should have inline behavior overridden."
+  (let ((types mm-inline-override-types)
+	(type (mm-handle-media-type handle))
+	ty)
+    (catch 'found
+      (while (setq ty (pop types))
+	(when (string-match ty type)
 	  (throw 'found t))))))
 
 (defun mm-automatic-external-display-p (type)

Re: HTML recognition

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> I've had great success using
>   (setq mm-discouraged-alternatives '("text/html" "text/richtext"))
> because just about all HTML mails include a plaintext alternative
> (which raises the question, why bother with the HTML?).

The MIME RFCs says that the default should be to display the "best"
alternative.  The best is the richest, I think.

> The only time this has failed was when the alternatives were text/plain
> and multipart/related - the HTML was inside the Related (the idiot had
> included an image - presumably a company logo - in his/her spam).

You need to discourage multipart/related, I think.  Hm.  Does that
work? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: HTML recognition

[Lars Magne Ingebrigtsen]

dsg@mitre.org (David S. Goldberg) writes:

> Anyway, with my settings, I only have w3 process the html when I want
> it so I'm reasonably happy with it.  If I could just find an easy way
> of treating all html stuff as attachment instead of inline, I'd be
> even happier.  Modifying mm-inlined-types isn't appealing since my
> experience with regexps says that there's no reasonable regexp to
> "match everything except html"

The third element is a predicate that says whether you can display the 
type inline or not.  Setting it to `ignore' should do the trick, since 
that function returns nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: HTML recognition

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The MIME RFCs says that the default should be to display the "best"
> alternative.  The best is the richest, I think.

The best is the one that comes last, so when text/plain and text/html
alternatives are present, text/html comes second, and Gnus (correctly)
shows that one.

Re: HTML recognition

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> > The MIME RFCs says that the default should be to display the "best"
> > alternative.  The best is the richest, I think.
> 
> The best is the one that comes last, so when text/plain and text/html
> alternatives are present, text/html comes second, and Gnus (correctly)
> shows that one.

Yeah; that's right.  I'd forgotten we'd fixed that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Discouraging multipart/related (was: HTML recognition)

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> In <URL:news:m3eme3uyn8.fsf@quimbies.gnus.org>, Lars wrote:

Lars> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

>> The only time this has failed was when the alternatives were
>> text/plain and multipart/related - the HTML was inside the
>> Related (the idiot had included an image - presumably a company
>> logo - in his/her spam).

Lars> You need to discourage multipart/related, I think.  Hm.  Does
Lars> that work?

Only if the only multipart/related parts I get are HTML-centred (true
now, but not necessarily for ever).  The problem is the same if you're
discouraging any other multipart/* - you don't want to do it without
knowing what's inside the multipart.  Except multipart/digest, where
you know the contents are all message/rfc822.

But as I said, it's not a big enough problem to worry about just yet.