lynx-dev
[Top][All Lists]
Advanced

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

Re: "mailto:" + EXTERN wishlist [lynx-dev]


From: Vlad Harchev
Subject: Re: "mailto:" + EXTERN wishlist [lynx-dev]
Date: Mon, 7 Jun 1999 07:00:02 +0500 (SAMST)

On Sat, 12 Jun 1999, Klaus Weide wrote:

> On Mon, 7 Jun 1999, Vlad Harchev wrote:
> 
> > On Sat, 12 Jun 1999, Klaus Weide wrote:
> > 
> > > On Sun, 6 Jun 1999, Vlad Harchev wrote:
> > > >  We can extend the syntax of EXTERNAL command - for example %s will 
> > > > still be  
> > > > substituted with url, and %t substituted with value of the TITLE 
> > > > attribute. Of
> > > > course this will complicate handling, but this worth it.
> > > 
> > > The more fundamental problem is how to make the TITLE survive from HTML_*
> > > to links[].  The question how to handle TITLE *attributes* (not <TITLE>
> > > elements) better came up recently in connection with <LINK> elements.
> > 
> >  It's implementable. In lynx_help/lynx_url_support.html there is a 
> > description
> > of "mailto:"; variations supported by lynx. The obsolete (but still
> > supported) one is
> >     href="mailto:address@hidden";
> > so we can create such urls and store them in links[] if there is TITLE
> > attribute of 'A' element, and then extract subject when EXTERNAL is invoked.
> 
> It's not obsolete - on the contrary, it is now allowed by RFC which
> extends the mailto: syntax (in an incompatible way to the old
> specification, thus the bias in the Lynx documentation against it).
> 
> You are proposing a terrible hack here: Messing up a perfectly fine URL,
> valid according to old and new spec, to become something valid only
> according to new spec.  Also there are lots of special cases that would
> have to be ironed out (URL escaping, what if subject is specified in both
> forms, what if URL has some other ?keyword=..., etc..)

 But IMO sort of hacks is preferable than adding some field that will always
be in struct but used very seldom. Another kind of such trick - add required
info at the end of the url string (ie after 0 character - so url will be
pretty clean for string functions, but special information will be placed
after that 0 and between next 0). In this case (not adding special info as
part of url but adding it after the url string) won't require escaping, etc..

> Moreover this would only work for mailto: URLs, not for other cases where
> TITLE also may be useful.
 
  Another approach I proposed in this letter can solve the problem. But I
can't imagine where else title information can be useful.

> >  This leads to another technique - don't add fields to the links[], but 
> > append
> > specific strings to urls for futher use (not only for mailto urls).
> 
> Maybe it doesn't have to be added directly to links[], but to the HTLink
> struct to which links[n] points in some indirect way.
> 
>    Klaus
> 

 And anyway, we will have a lot of trouble escaping subject string when
invoking the shell (if lynx invokes shell for EXTERNAL command).
  
 Best regards,
  -Vlad


reply via email to

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