lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Re: external mail programs


From: Klaus Weide
Subject: Re: lynx-dev Re: external mail programs
Date: Thu, 6 Jan 2000 04:00:36 -0600 (CST)

On Thu, 6 Jan 2000, Eduardo Chappa L. wrote:
>                                                             I have never
> intended to make this as a patch for lynx, but more as a patch for "pine
> users" rather than for lynx users (although you can try to argue that this
> is false, 

No I can't - don't understand the difference at all :)

> my idea is that pine users can use pine to compose messages in
> lynx, rather than lynx users use pine to compose messages - I hope that
> explains why I never really submitted the patch).

That's too metaphysical for me, or something.

> I had not thought about
> the fact that things like including the original article/page were lost,
> but you are right, and that has a fix, which I expect will be easy.

I'm afraid not so easy - maybe not a problem if you have just pine
in mind (and just a certain version & above) and just Unix (I don't
know the calling convention but you probably do, if there is one).

> My only real point here is that users should have the option of
> configuring which mailer to use. 

Sure, in principle I agree.  Who wouldn't?  The devil lies in the details,
lots of them.

I could start asking what those words you use mean.  What is a 'mailer'?
(MUA? MTA? more? less?)  And what kind of 'use' are you thinking of?
(For what - sending a new initially empty message? replying to a page
with quoting? do full folder management while running 'under' another
program?).  And what kind of 'configuring'?  (Apparently setting up
an EXTERNAL: line in lynx.cfg is not acceptable in your opinion, but
it IS a way of 'configuring which mailer to use'.)

> Browsers like Opera allow you to do so,
> for example, as I read today in a web page.

Given just that statement ('Opera allows you to configure which mailer
to use' or similar), I don't really know more than before.  See
questions above.  Seems a statement fuzzy enough to have just
marketing value.

> Although this does not seem to
> be of great importance in a browser for some of you. I believe that today
> a mailer and a web browser are the two most used internet products. It
> would be nice if both of these products allow you to open by default
> the other one.

Part of the problem is, there is no standard (portable) definition of what
'opening' is.  There is no given interface to 'a mailer' that you can
more or less rely on to be there.  About the only thing that's kind of
standard (but not always) in the Unix world is the sendmail interface (not
SENDMAIL.EXE), and that's what lynx is using.

> My mailer certainly can be configured to open my default
> browser, 

Well, there seems to be a kind of regular way to call a browser for
a given URL ('open'), and that's 'pass the URL on the command line'.
I don't know that there's a similar reliable/universal convention for 
'mailers'.  You'd want to pass different kinds of things anyway -
recipients, folders, a file to send, to name a few, depending on
what you use the 'mailer' for.

> without me needing to do anything different from what I normally
> do and that's what I expect of my browser with respect to my mailer too.

So it's all a matter of using <Enter> vs. '.'?

> I hope someone can write a nice patch for lynx to do this, although it
> must not look important for many of you.

I admit it doesn't, to me...  Having all that mail-sending stuff
*cleaned up* ('Somebody ought to do it') so system-specific complete
brokenness doesn't go undetected for months so easily (like we just
had) would be more important IMO.

But - if *you* want patch lynx for a limited purpose, so that it fits
your needs better - go right ahead, just as you did.  You can
circumvent all the features and platform code you're not interested in
(like you seem to have done in your patch, by removing the code).

Another, more general way to make basic mailto: activation more
configurable (Henry should like this one):

Remove the MAILTO_URL_TYPE handling code in LYGetFile.c that 'preempts'
going through the regular HTLoadAbsolute().  I.e., remove the branch
starting on the line

                } else if (url_type == MAILTO_URL_TYPE) {

Then mailto: should be subject to RULEs, mailto_proxy (probably...),
or other tricks to let it be handled by lynxexec / lynxcgi / whatever
else you have.


   Klaus


reply via email to

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