bug#9300: 24.0.50; `bounds-of-thing-at-point' does not return nil when just after THING

[Drew Adams]

> > > FWIW, I agree with Dmitry: this has been a de-facto behavior long
> > > enough to consider it the correct one. If documentation is confusing
> > > in that it says otherwise, we should fix the documentation.
> >
> > I couldn't disagree more.
> >
> > It is wrong to consider the current behavior "the correct one",
> > regardless of how long it has been in place.  It is wrong because
> > you cannot use it in a general and precise way.  It is just broken.
> > It has been broken for a long time, but it is broken nevertheless.
> 
> That's immaterial.  It is being used in many places, and it's
> obviously useful.

It is not being used in _any_ place where it matters whether
there is a thing just before point but not at point.  It cannot
be used in such a place because of this bug.  Can you point to
such a use?

"It is obviously useful" ONLY for cases where you don't really
care _whether_ there is a thing at point and you only want to
get a thing at point or at point-minus-one - you prefer to get a
thing rather than nil, even if the thing is not quite at point.

Sure, such behavior can be useful if that's what one wants, and
"it is being used in many places" - to just grab something to
use as a default value.  But it is not always grabbing a thing
at point.

Just rename this grab-for-defaulting function: "*-near-point"
or "*-at-or-just-before-point".  It is not _at_ point.

> Somewhere in this long discussion there was a suggestion to
> add new functions that behave like you want.

It is not about what I want.  It is what "at point" means.
At_point_or_at_point_minus_one is not the same thing as at_point.
Currently the behavior is the former, not the latter.  That most
people don't notice or care about that is immaterial.

I already provided a correct implementation for at-point behavior.

And I already provided an implementation for near-point behavior,
albeit a better one than just at_point_or_at_point_minus_one.  For
the latter, you already have the current, broken implementation -
just rename it "*-near-point*".

> I suggest to invest energy in that direction, instead of more
> bikeshedding.

I'm not bikeshedding.  And I'll thank you to drop such a
characterization.  This is a real bug.  That you don't recognize
it is too bad.

I already invested energy in providing the function needed,
i.e., in fixing, as well as reporting, this bug.  And I (and
others) have been using the fix for decades.

I pointed you to code that provides not only the needed behavior
for `bounds-of-thing-at-point' but also other improvements for
thingatpt.el.  If you are uninterested, that's too bad.

> That way, everyone is happy, and you even get to prove you
> are right, if at some future point in time we will find that
> most applications switched to the new APIs.

Unlike some, I'm not really interested in proving I'm right.
But if you are interested, the proof is that you cannot use
the current code to distinguish whether there is a thing at
point from whether there is a thing at point-minus-one.

Can you point to a single use of thingatpt.el code that does
more than just use a thing at-or-just-before point as a
default value?  Can you point to a single use that really
cares about whether there actually is a thing at point, and
is not just trying to grab a thing near point?  A use where
a nil value is actually useful and taken into account as
more than simply a lack of a default value?

I don't think you'll find any (other than uses of my code).
This bug prevents using thing-at-point that way (general,
precise).  It confounds a thing at point with a thing at
point-minus-one.

I have what I need, in my own code.  You've heard in this
bug thread from a couple other users as well.  Lousy
bikeshedders too, no doubt.  But one of them has written his
own code that builds on thingatpt.el, and has clearly been
interested in thing-at-point and knowledgable about it for
years.  The other has contributed several uncontroversial
and non-bikeshed bug fixes to Emacs recently.

You will not hear from lots of others about this, naturally.
If one does not try to use thing-at-point to actually see
whether there is a thing at point then one will not even
notice this bug.

But if the bug is fixed then all kinds of possibilities
open up for handling multiple occurrences of a thing etc.,
possibilities that are precluded today, simply because the
code cannot tell the difference between there being a thing
at point and there being a thing at point-minus-one.
Dommage.

And if you fix this bug what happens to those who are using
the code today only to get a default value?  If point is
after a thing, and there is NO thing at point, then they
will get no default value.

If they complain about that in some context, you have only
to point them to your new `*-near-point' function for the
behavior they think they miss.  And for any occurrences in
Emacs code where you think that is the behavior you want,
just use the new function.

It's pretty simple, really.  If you want to improve Emacs
for thing-at-point, apply the one-off-bug fix and also
offer another function that maximizes returning a thing
rather than precisely getting a thing at point or returning
nil if there is none there.

My suggestion for the `*-near-point' function would be to
do something like what I did, letting users and code
control how near "near" is in any given context.  But if
you want to keep it rudimentary, where "near" means only
at point or at point-minus-one, then just rename the code
you have now to `*-near-point'.