lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev External Mail programs


From: Henry Nelson
Subject: Re: lynx-dev External Mail programs
Date: Mon, 3 Jan 2000 15:56:28 +0900 (JST)

> >:) Does mime treatment of file extensions, ".gif" and ".pdf," have anything 
> >to
> >:) do with a protocol, "mailto:";?
> >:)
> >No it does not, but the point is that there are many ways to treat
> >different choices, It is my opinion that anything which is not
> >[12]http://foo.com/bar.html should be treated in special ways. mailto: can be
> >treated by opening an external mail program, like you do with any of your
> >other choices. In another words, what I am saying is that there is no need
> >for the external command, maybe all this is leading to the external
> >command being associated with the return key (too).
[...]
> Henry, I think that what you don't want is a bigger executable, no?

NO!  Not an issue.  (How many lines of code was it, 20?)

> As far as the UI is concerned, I tend to agree with Eduardo that it would
> be more logical if mailto: could be bound to an external call by extension,
> just as display of MIME types is helped by extensions.

Was Eduardo saying this?  If so, then I really do not understand and need
to be educated.

Aren't http://, ftp://, telnet://, and mailto: protocols, whereas extensions
like .html, .txt, .gif, .pdf say something about what form the "document" is
in?  Can a mailto: URL have an extension?  I thought about all that would make
sense there is an e-mail address, some address@hidden

Eduardo says "anything which is not http://foo.com/bar.html should be treated
in special ways."  My point is that Lynx DOES ALREADY treat both anything
different from "http://"; and ".html" in APPROPRIATE ways.

He also says "there is no need for the external command."  That is quite
true!  Most of us got along fine without it until Wayne hit a stumbling
block in the Win32 port with not being able to support ftp:// protocols.
Pretty much the same thing can be done easily with lynxcgi, lynxexec, or
lynxprog, at least on Unix.

Since then it was found that the EXTERNAL mechanism was really nifty for
doing things like downloading in the background (wget, w3m, ftp) or
calling up a mailer with site-customized command line options.  I say
this is BETTER than some hardcoded, configurable or not, handling of a
URL.  It is ultimate freedom to do whatever you want without forcing a
stitch of one's personal preference as to a UI onto anyone else.

Finally, I didn't understand "the external command being associated with
the return key."  I thought it was simply ".".

I'm sorry, but I don't buy the "it's too hard for the user to figure out"
argument, either.  There are very good step-by-step howto's documented
in the flora archives for both mutt and pine.  The explanation in lynx.cfg
is fairly thorough.

In short I'm simply saying we've got a product that is superior exactly
the way it is.  Adding code to make mailto: configurable sorta like
telnet:// or ftp:// does not make Lynx better, IMHO.  Thus, I ask why?

__Henry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]