[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH]
Re: lynx-dev [PATCH]
Fri, 23 Jun 2000 23:24:37 +0500 (SAMST)
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:.
Itr won't since not modifying URL is more generic. The mailto:-stripping
one-liner should be used.
> 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.
The original version won't bring external program in case of 'g' command.
This is very easy to fix - thank you for reminding (also 'E' and 'G' commands
should should be supported too). Probably no-cache ('x') command needs support
too (I find now that it's more reasonable to support it). But on the other
hand, I'm begining to think (thank to you) that this patch is useless and
another is required. Read below.
> 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. (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).
> I think the only difficulty posed with using CERN RULES is the ability to
> include the original post. 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.
Thanks to you, I reread the cernrules.txt and now it seems to me that cern
rules are a better way of implementing functionality intended (plugging in
support for protocols lynx does and doesn't understand). I hope it works right
- I never used it. But CERN rules need more work on them - I think mailto:
URLs shouldn't be in the list of URL types that are not considered by CERNRULES
(i.e you wouldn't have to invent xmailto: URL - you could install cern rule
redirection for mailto:).
And of course my original patch didn't support quoting original post too.
> > 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.
I don't think it's against specs - otherwise any human won't be permitted to
issue "cd" command without relogging in. ftp protocol would be stateless then
(like http - just "tell the name of the document, get it and disconnect").
> > 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?
Seems there shouldn't be any (at least if using CERN rules). As for my
patch, user can press 'x' and get original behaviour (since it's different
command) but if development of original patch continues, that trick with
'x' command would have to be removed (so there won't be any way to get
standard built in lynx functionality).
> Mike Castle Life is like a clock: You can work constantly
> address@hidden and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
> We are all of us living in the shadow of Manhattan. -- Watchmen
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden