RE: address@hidden: 23.0.0; (thing-at-point 'url) returns invalid urls]

[Drew Adams]

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

Admittedly, it says "is unlikely to be accessible", not "is not accessible".
But the subject line of the thread is "... returns invalid urls". Since the
URLs in question are syntactically valid, and people do sometimes refer to
URLs as "invalid" when their targets are not live, I guessed that
inaccessible target was what was meant.

Putting it all together, it's not clear to me just what those who don't like
the current behavior would prefer.

I like the current behavior, so I don't really care what additional
behaviors are offered. I do hope that the current behavior will be the
default, however. In terms of Thi's patch, this means that the new variable
he introduced has the wrong default value, for me (it is also a defvar, not
a defcustom). The current behavior is better.

What alternative behavior is being requested for each of the following cases
(text under cursor). Return nil? Return the text as is? Return the text with
http:// prepended unless there is already a URL scheme? (The currently
returned text is indicated in parens, when it differs from what is at
point.) Assume that http://nosuchlivetarget does not point to a live target
(now or usually).

a. nosuchlivetarget   (http://nosuchlivetarget)
b. http://nosuchlivetarget
c. www.google.com     (http:/www.google.com)
d. http://www.google.com

Under the two interpretations above, the result would be #1, #2:

1. "valid" meaning has valid URL syntax that includes a scheme: (a) nil, (b)
http://nosuchlivetarget, (c) nil (d) http://www.google.com.

2. "valid" meaning has a live target (either now or usually): (a) nil, (b)
nil, (c) http:/www.google.com, (d) http:/www.google.com.

3. Stefan's criterion is "likely to be meant as a URL". That might give the
same result as #2, but he rejected link testing as the means. Perhaps,
depending on the heuristic used, the result he expects is this: (a) nil, (b)
http://nosuchlivetarget, (c) http://www.google.com, (d)
http://www.google.com. One could argue that both (b) and (c) are likely to
be meant as URLs. Dunno what the heuristic would be.

4. Thi's patch (with new variable = nil default value) gives this: (a)
nosuchlivetarget, (b) http://nosuchlivetarget, (c) www.google.com, (d)
http://www.google.com.

Thi's patch doesn't seem to fit the OP, regardless of interpretation, since
it returns nil only if the thing at point is not even a simple URL (without
scheme) - for example, when point is over whitespace or punctuation. The OP
clearly wanted nil for "something" (whatever the reason - whether no URL
scheme or inaccessible target).

So what alternative behavior do people want?