Bug 49228

Neither /etc/mailcap nor /etc/Muttrc is the responsibility of links. Assigning 
to mutt.

implicit autoview doesn't sound like a good idea, security wise.

This, NTITAI, would also make stuff in xterms use links, which is probably
not what people would want.

what is "NTITAI"?

[1] part of the original bug report assigned to LINKS module was that links 
comes with NO USEFUL DOCUMENTATION.  PLEASE GET THAT FIXED.  WHAT GOOD IS A 
PROGRAM THAT YOU CAN'T FIGURE OUT HOW TO USE?

[2] security and mutt/mailcap autoview...  what about functionality?  text/html 
MUST work because it's becoming so ubiquitous...to not provide it is to provide 
a crippled and dysfunctional product.  the fear/complaint/excuse that links is 
insecure (or any of the other things with the copiousoutput flag in mailcap) is 
an issue for the other modules to address...links doesn't do javascript, so 
what's the big deal?  if links is insecure then FIX LINKS OR DON'T SHIP IT.  

mutt, however really needs to support text/html.

[3] xterms?  you mean terminal applications in the generic sense?  xterm is 
pretty much deprecated these days and most people are using terminal programs 
that allow you to click urls.  gnome-terminal and kde's equivalent at least.  
if i'm reading mail in a terminal window, i want it all to stay in that 
terminal window.  if i want to visit urls in another window, there's a way to 
do that as well.  

in fact, it is better UI consistency for a mouse-oriented application (because 
you really cannot effectively navigate through netscrape without the mouse) to 
be INVOKED by use of the mouse...(eg: ctrl-click or right-click-->"open in 
browser"-->route through gnome browser settings)

Assigning back to links for the documentation issue.

My concern is that automatically viewing attachments of any type is a bad idea.
However, when someone running a terminal application chooses to view HTML
while running under X, they may want to use Mozilla or something similar to view
it.

NTITAI == 'now that I think about it'.

notting sez: "when someone running a terminal application chooses to view HTML 
while running under X, they may want to use Mozilla or something similar to 
view it."

is it not reasonable to assume that [a] if people want to use mozilla for 
reading text/html email they will use the mailer support in mozilla?  [b] if 
people are primarily engaged in an activity they call READING MAIL, they will 
want to hold their focus on the mail-reading-application, which happens to be 
in a terminal window running mutt?

the fact that i have to go on a fucking egg hunt just to read my own fucking 
email is pretty much the reason that linux inspires about as much computer 
hatred as windows...  there was once the dream of "the right thing" but that 
has now been lost in the complete lack of a consistent vision for the user 
experience!  if i'm running an application in a terminal window, i MAY want to 
switch my attentional focus to the WIMP interface, but that MUST BE an explicit 
action on my part, not some willy-nilly "users might want X" supposition...

right now, there is NO SUPPORT FOR READING text/html mail from a 
terminal...either by invoking mozilla or not...you have to read the shit by 
piping to less(1), which is utter bullshit...and it's impossible to fucking 
REPLY to a text/html mail (unless you do the mailcap/copiousoutput patch i 
sent) with the text of the original message included...

and you want to impose upon users the experience of cutting & pasting from a 
browser, deleting that window, then doing a separate operation in the original 
terminal window (which has probably lost keyboard focus!!!)...  shit, fuck, 
damn, blast, frak, felgercarb, zoinx, ick, gork, urk, blech, (note that i'm 
calming down and my language is improving), ...

redhat linux will NOT be recommended in my next published article on linux.

summary: redhat ships things with poor packaging, missing documentation, and 
poor integration.  (incidentally, it's totally stupid that i can't install 
xemacs from redhat's rpms without also running a (*&(*&@^#*(&(% canna 
server)...just because there's optional MULE support in xemacs doesn't mean 
that it ought to be enabled in the US distribution of the OS)

       windows you can't keep working and linux you can't get working,
       stig

For the documentation issue: /usr/share/doc/links-0.95/README *is* there and 
included in the package, and it's the only up-to-date links documentation 
anyone has written.

Come to think of it, the links-manual back from 0.82 is still mostly valid; 
I've added that to the 0.96-2 build.

Assigning to mailcap (which has /etc/mime.types) so we can think about adding 
some html viewer for text/html.
IMO this should point to "htmlview" rather than links though. (htmlview 
invokes links, lynx, konqueror, mozilla or netscape depending on what is 
installed and the present environment).

added in mailcap-2.1.5-1.

the testing and usage requirement/goal must be that a user using mutt be able 
to transparently read and reply to text/html email (using mutt because with 
mutt it's possible, pine and other mailers may also work).  automatic 
functionality inside a terminal window is of the utmost importance.

viewing html is NOT half so important as seamless conversion back to text!!!

from a casual examination, however, it seems evident that mailcap provides 
multiple access methods (look at the andrew stuff...mailcap was developed by 
the same folks) and so it seems likely that external viewing can/should be 
accessed through the "(v)iew attachments" functionality that is the current way 
to view attached images...  i'm sure that the mutt maintainers would accept a 
patch to allow both internal and external viewing if it came to that.

     stig

there is another hassle/caveat/problem involved in this text/html 
mess...currently if you set implicit_autoview in mutt, it preferentially 
chooses the html version from text/multipart emails instead of the text 
version.  that's undesirable behavior.  the functionality should be:

   normal viewing:     text if available
                       converted html if no text available
   (v)iew attachments: a more interactive viewing mode (eg links w/o -dump flag 
or external viewer if running under X)

text/html has been in mailcap for a while.