lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [PATCH]


From: Klaus Weide
Subject: Re: lynx-dev [PATCH]
Date: Fri, 7 Jul 2000 14:38:09 -0500 (CDT)

Regarding the original EXTERNAL-based patch from Vlad:

On Thu, 22 Jun 2000, Mike Castle wrote:

> On Thu, Jun 22, 2000 at 08:39:07PM +0500, Vlad Harchev wrote:
> >   It turns out that Eduardo wrote a patch that allows invoking pine for
> > composing letters when mailto: link is activated (as I understood). If my
> > patch is applied, then by adding to lynx.cfg
> > EXTERNAL:mailto:some-pine-wrapper-stripping-mailto-prefix %s:TRUE:TRUE
> 
> Hmmm... I thought this patch also stripped the mailto:.
> 
> Anyway, does this patch handle the case where I can hit 'g' to goto a link
> and type mailto:address@hidden and expect it to bring up this mail
> program?  If it doesn't, then I'd consider that to be a major flaw because
> it would provide a very inconsistent interface.

Inconsistent - maybe.  Not if you think of Enter/Return as just a
convenient alternative for '.'.

> On the other hand, I believe I could use CERN RULES to handle something
> like  xmailto:address@hidden and do the right thing.  Though I've
> never played with it. I'm hoping KW will comment though.  

I am glad one person appreciates the beauty of the "Tweak the URL with the
Line-Editor" approach. :)
But apparently there are folks who cannot be bothered to press '.' instead
of Enter or Right Arrow sometimes.  Otherwise there would be no demand
for Vlad's patch.  I don't think you can sell TTUWTLE to those folks.

As long as you are willing to use xmailto: (NOT mailto:) and use the Line-
Editor, yes you can already do that; with the usual drawbacks (opening
up lynxexec/lynxprog or lynxwhatever execution, and have to set a fake
xmailto_proxy).  Vlad's revised patch (or my suggested change thereof) is
only needed if you want to be able to handle mailto: (without X) the same way.

> (By the same
> token, this mechanism could replace EXTERNAL altogether, and had it been
> as well explored at the time, EXTERNAL might not have gotten in; just E,
> c-A, x, RET).

That's possible; but EXTERNAL is still better for what it does: invoke
specific commands on specific types of URLs.  Without requiring to
allow other kinds of execution links or similar.

> I think the only difficulty posed with using CERN RULES is the ability to
> include the original post.  

If you want to be able to do that, we need to have a mailto-*specific*
way to hook in an external command.  It doesn't make sense to pass the
"original post" to a generic external-command hook; "original post"
usually doesn't make sense.  And saving the "original post" (or page)
to a file is significant overhead.  (How else could it be passed along?)

> I'm not sure if the current URI is passed along
> anywhere, or just the URI being followed, so can't even use lynx -dump.
> And, of course, probably no easy way to pass along the current formatted
> text.  Perhaps energies could be better spent enhancing CERN RULES.

It's a problem either way.

> >  user will be able to use pine for composing letters. Also see the example 
> > for
> > using 'links' browser for browsing ftp sites - this patch looks like a very
> > useful addition.
> 
> Btw, isn't the caching of ftp sessions against the specs?  Just thought I'd
> seen something about that.

1. No, 2. lynx doesn't care too much what specs say even about HTTP
caching - its "parsed document" or "source" caches don't really behave
as caches according to the HTTP specs.

> >  Of course, user can press '.' instead of enter - but IMO it's easier to 
> > make
> > lynx slightly wiser than remind user about this.
> 
> Also, let's say, instead of using the EXTERNAL command, the user wants to
> use the standard built in lynx command occasionally.  What's the mechanism
> for that?

Yes, I think there should be one.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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