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

[Vlad Harchev]

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 Mon, 7 Jun 1999, Vlad Harchev wrote:
> > > >  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";
> > >[...]
> > > 
> > > 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..
> 
> *Shudder*
> I really hope you are joking.

 I was serious. And I don't think it's so crazy idea.

> > > 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.
> 
> Title information can be useful if people put useful information into
> TITLE attributes.

  But I still don't see any use of it _AFTER_ text is rendered. Of course
while rendering text we can somehow insert TITLE information in the rendered
version, but after it was rendered, seems it's only useful for mailto: links.
Please correct me if I'm wrong.

> Use of TITLE attributes has just come up in connection with <LINK>
> elements.  Admittedly not with respect to EXTERN.  But if "%t" (or
> whatever you choose) should mean <value of TITLE attribute here> for
> mailto: URLs, I don't see any good reason why it should mean anything else 
> for other URLs.
> > > >  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).
> 
> And make URL parsing more messy than it already is.
> 
> Structs are your friends!

   RAM is our friend too.

> Embedded NUL characters only if you have to hide something...

  Yes, this will hide additional info from other modules that don't know about
it. Seems that it's good solution - just look after the end of string only if
handling EXTERNAL command and if url name begins with 'mailto:'.

> > > 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.
> > 
> >  And anyway, we will have a lot of trouble escaping subject string when
> > invoking the shell (if lynx invokes shell for EXTERNAL command).
> 
> Maybe it does not need more protection than what's already there for
> filenames that are passed to a shell command.  Although putting the title 
> in an environment variable might provide for a cleaner separation than
> something like (a second) %s or %t in the string.

 Nice idea - putting additional info in the environment. Seems it's better
than second %s or %t.
 
> 
>   Klaus
> 

 Best regards,
  -Vlad