Bug 49228 - links: no documentation & no integration
Summary: links: no documentation & no integration
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mailcap
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-17 05:47 UTC by Stig Hackvan
Modified: 2014-03-17 02:21 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-02-07 21:13:38 UTC
Embargoed:


Attachments (Terms of Use)

Description Stig Hackvan 2001-07-17 05:47:02 UTC
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

Comment 1 Bernhard Rosenkraenzer 2001-07-17 09:33:53 UTC
Neither /etc/mailcap nor /etc/Muttrc is the responsibility of links. Assigning 
to mutt.


Comment 2 Bill Nottingham 2001-07-17 16:32:47 UTC
implicit autoview doesn't sound like a good idea, security wise.


Comment 3 Bill Nottingham 2001-07-17 17:45:02 UTC
This, NTITAI, would also make stuff in xterms use links, which is probably
not what people would want.

Comment 4 Stig Hackvan 2001-07-17 19:01:46 UTC
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)


Comment 5 Bill Nottingham 2001-07-17 19:46:13 UTC
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.

Comment 6 Bill Nottingham 2001-07-17 19:47:04 UTC
NTITAI == 'now that I think about it'.

Comment 7 Stig Hackvan 2001-07-17 22:54:06 UTC
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


Comment 8 Bernhard Rosenkraenzer 2001-07-18 10:52:11 UTC
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).



Comment 9 Bill Nottingham 2001-07-18 14:36:57 UTC
added in mailcap-2.1.5-1.

Comment 10 Stig Hackvan 2001-07-18 16:41:24 UTC
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


Comment 11 Stig Hackvan 2001-07-18 17:06:23 UTC
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)



Comment 12 Bill Nottingham 2003-02-07 21:13:38 UTC
text/html has been in mailcap for a while.


Note You need to log in before you can comment on or make changes to this bug.