RE: Re: [External] : Re: Adding custom providers for thingatpt.el (was: [PATCH] Add support for 'thing-at-point' to get URL at point)

[Drew Adams <drew.adams@oracle.com>]

> * Drew Adams <drew.adams@oracle.com> [2024-05-08 21:17]:
> > >> At the risk of veering off-topic (I mainly care about adding
> > >> 'bounds-of-thing-at-point-provider-alist' and
> > >> 'forward-thing-provider-alist'), would adding a new optional STRICT
> > >> argument to 'thing-at-point' and friends be an ok resolution for
> > >> everyone? This argument would enable Drew's proposed behavior. That
> way,
> > >> users get all the nice behavior by default just like today, and
> > >> programmers who require strict correctness in their code also have an
> > >> option.
> > >
> > > 1+ if STRICT means thing starting at point
> > > and without it we may need to look for the
> > > beginning of the thing (lazy point setting)....

Please don't (presumably accidentally) make it
look like you're responding to something I wrote,
but you actually quote two others - nothing at
all from me.  Thx.

> I was of understanding that it is the regular
> expression that decides what is on the point or not.

What regular expression?

Are you thinking of a regular expression that's
checked to see if some particular kind of thing
is at point, e.g. a regexp like the value of a
var such as `thing-at-point-newsgroup-regexp'?

Such a regexp doesn't determine/define what "at
point" means.

The question here is where you test for a thing
at point, i.e., what "at point" means.  It's not
about how you test that.  If your test function
actually checks something at a char that's not
at point, that's its prerogative.  It's about
the generic behavior of Thing At Point.

The char at point (which actually means the char
just after point) is well-defined.  That's what
the generic functions `bounds-of-thing-at-point'
and `thing-at-point' use as starting point.
Then then move forward and backward a THING etc.
to see if there's such a THING at that starting
point.

That movement is customizable (with properties
`forward-op', `beginning-op', `end-op',
`bounds-of-thing-at-point', `thing-at-point',
and in other ways).  But the starting position
is `(point)'; that's where the check is done.

The bug is in `bounds-of-thing-at-point'.  It
should be faithful to its name, and check only
at (point), not at EITHER point OR (1- (point)).

Even if the fix were to always check only at
(1- (point)), instead of (point), it would be
a legitimate fix for the problem caused by the
ambiguity: there's _no way to determine whether_
there's a thing at a given position.

The bugged behavior defeats the successive use
of functions that do something with _the next
thing_ at point when that _next thing butts up
against the previous thing_.

IOW, it technically doesn't matter which single
position is the "origin" for checking: (point)
or (1- (point)) or whatever else.  The bug is
that _no single_ position is used.

However, since "at point" does mean something
in Emacs English, the proper fix is to always
check starting from (point), not (1- (point))
or any other position.

Either always-(point) or always-(1- (point))
would be a fix.  But always-(point) is the
better/proper fix, just because it accords
with Emacs terminology.