Hi,

On Fri, Aug 31, 2007 at 04:57:04PM -0700, Drew Adams wrote:
> >    That's OK too. I thought people were asking for the ability to
> >    get only "valid" URLs in the sense of having live
> >    targets. Isn't that what the initial request was for?
> >
> > iiuc the initial request was to disambiguate the two cases whereby
> > (thing-at-point 'url) when point is on one of:
> >   something
> >   http://something
> > (both cases return "http://something").
> 
> Admittedly, the text of the initial bug report (OP) is not too clear:
> 
> >> Put the point in any word but not in a url and eval (thing-at-point
> >> 'url) it will returns a url like "http://something", where 'something'
> >> is the word under point.
> 
> That and other posts seem to suggest that the requested (optional, perhaps)
> behavior is to return nil unless the URL under point contains a scheme (e.g.
> http://, ftp://). For example, "something" at point and www.google.com at
> point would each return nil.
> 
> However, other posts seem to suggest that the perceived problem is that
> http://something is not a "valid" URL because the target is not (currently
> or perhaps usually) live (accessible):
> 
> >> Because a url created by concat "http://" and the word under point is
> >> unlikely to be accessible by a browser.

Come on, people. If the point is above `something' and I don't want EMACS to
return an URL-string but NIL, why would I run (thing-at-point 'url) in the
first place? This is bogus.

I like the behaviour as it is right now. Returning nil is as unusable as
http://something for most, but for some people, http://something can still be
of use.

	Hannes