bug#74132: 31.0.50; thing-at-pt, ffap and Github markdown

[Stefan Monnier]

>> > What will this do to URLs such as
>> >   http://web.archive.org/web/20240221082647/https://www.imdb.com/
>> Depends where point is: if it's after the `https`, then you get the
>> "sub-URL" and if it's on or before the `https` then you get the whole URL.
> Exactly.  This could be considered a bug, because the actual URL is
> the entire thing.

We could refine our heuristic to as to keep looking backward when the
apparent beginning of the URL is immediately preceded by a /, of course,
but I'm not sure it's worth the trouble.

AFAICT any behavior we come up with will have such cases.

>> > I'm not sure I see how to resolve this dilemma.  Stefan, any ideas?
>> "url at point" is inherently heuristic, so I'm not too worried.
>> But I do very much agree with Stefan that we need tests, because it's
>> all too easy to run around in circles otherwise, fixing the heuristic to
>> handle case A but breaking case B along the way.
> I'm okay with adding tests, of course, but I'm not sure which of the
> two behaviors leave you "not too worried": the current or the new one
> after the proposed change.  And why.

The [...](...) case mentioned by Madhu is a fairly common one IME, so
I'm in favor of fixing it.  As for the behavior in your example, to the
extent that the users can control which URL they get (depending on where
they place point (or click)), I'm OK with either behavior.


        Stefan