Red Hat Bugzilla – Bug 49228
links: no documentation & no integration
Last modified: 2014-03-16 22:21:47 EDT
Description of Problem: redhat is now shipping links (a text-based Web browser) but it is (a) undocumented (there is a manual on the home page, so that's a start) and (b) not integrated as a mime-based filter so it can't be used to read html mail... beginning of a solution (eg seems to work for me but haven't used it very long) ## stig/crashtest (pts/5) -- Mon Jul 16 -- 21:48:11 ## ## /home/stig >> new /etc/{mailcap,Muttrc} --- /etc/mailcap~ Mon Jul 16 21:47:19 2001 +++ /etc/mailcap Mon Jul 16 21:44:05 2001 @@ -192,3 +192,7 @@ application/msword; ns="%s"; tmp=`mktemp -q /tmp/${ns}.XXXXXX`; \ /usr/bin/wvHtml "${ns}" -o ${tmp}; \ netscape "file:${tmp}"; /bin/rm -f "${tmp}" + +# stig: add links for benefit of mutt +text/html; /usr/bin/links -dump %s ; copiousoutput + --- /etc/Muttrc~ Fri Mar 2 19:52:27 2001 +++ /etc/Muttrc Mon Jul 16 21:19:11 2001 @@ -963,7 +963,8 @@ # remote machine without having to enter a password. # # -# set implicit_autoview=no +# stig: set this on to account for links(1) viewing of html +set implicit_autoview=yes # # Name: implicit_autoview # Type: boolean
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.