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: Klaus Weide
Subject: Re: "mailto:" + EXTERN wishlist [lynx-dev]
Date: Sat, 12 Jun 1999 17:04:36 -0500 (CDT)

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.

> > 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.

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!
Embedded NUL characters only if you have to hide something...

> > 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.


  Klaus


reply via email to

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