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

[Drew Adams]

> > * I agree with Drew that there is neither sexp nor list at point,
> >    so i would expect I), II), III) and IV) returning nil.

Tino agrees because he wants to make use of the difference between
there being a THING at point and there being no THING at point but
there being a THING at (1- (point)).

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

The proper thing to do is to:

  1. Fix this bug.  It is a real bug.

  2. Add a new function that provides the same behavior as the
     broken behavior that is current, or similar.  And call it
     "-near-point", not "-at-point".

More precisely, for #2 the use case you cite is only to maximize
grabbing a thing at or _near_ point.  In the case of the current
code, that means at point or at (1- (point)).  If all you care
about is grabbing something at either of those positions then the
code works for you.  If you try to use it more generally, it is
broken.  IOW, if you actually care about the difference between
point and (1- (point)) then you are out of luck.

A better, more general, near-point function looks farther from
point, up to some caller-specified distance (horizontally and
vertically).  That's the purpose, in my code, of variables
`tap-near-point-x-distance' & `tap-near-point-y-distance' and
function `tap-bounds-of-thing-nearest-point' (prefix `tap-' for
library `thingatpt+.el').

See the arguments given in the bug thread for why #1 is important -
why `bounds-of-thing-at-point' should be fixed as indicated.

It is important that one be able to use `bounds-of-thing-at-point'
and `thing-at-point' in a way that is accurate, precise, and
general, and not only to try to grab something that is near point.

In particular, this matters when the functions are used
programmatically to handle successive THINGs (of the same type)
in a buffer or region.  For that, there needs to be a clean
boundary between THING and no THING at a given position.  You
need to be able to test whether there is actually a THING at
point.

I've spent a lot of time with this code, and with a fixed version
of it, over the years.  My use cases go beyond just trying to come
up with a default value for a minibuffer read.

That doesn't seem to matter to those in charge here.  Too bad, but
so be it.  I'll continue to use my code (`thingatpt+.el'), so not
fixing this bug doesn't affect me much, directly.

But it does affect me, and it affects others too.  For me, it
means that other code, which makes use of this fix, must also
conditionally handle the case where a user does not have
`thingatpt+.el', even if the result is inadequate.

I recommend to users of my code that makes use of thing-at-point
features that they also use library `thingatpt+.el', but I try to
let that other code have some semi-workable fallback behavior for
the case where they do not use `thingatpt+.el'.

So yes, this is an added (and unnecessary) burden for me and
for users of my code.  But I've been dealing with it for years,
so it's nothing new.

The real loss, if you do not fix this bug, is for Emacs users who
do not use `thingatpt+.el'.  They will be unable to do things with
the `thing-at-point' code that they should be able to do, simply
because it is broken at the end-of-thing boundary.

But it has proven to be impossible to convince you to apply this
simple fix.  So be it.

I can only repeat that the proper solution is to fix this bug
and to also give users a new function that does what you and they
currently expect of `thing-at-point', for the use case of
providing a default value for something: be able to grab a thing
at or near point.

`thingatpt+.el' has existed since 1996, yet you argue that even
though the thingatpt.el code has this bug, it should not be
fixed because users (or you) are used to it.

  "Your reasoning seems valid, however by now this behavior is
   ingrained into my expectations of how thing-at-point should
   behave."

Your expectations come from using the code only to grab a
default value from the text.  You don't care about testing for
a thing at point.  You want grabbing text to work even when
there is no THING at point but there is a THING at (1- (point)).

It would be simple enough to tell users to use the new function
that gives you a thing at or _near_ point, if they want only to
retrieve some text to use as a default value.

You make changes all the time to Emacs code that necessitate
3rd-party code using (if (fboundp 'AAA) BBB CCC) tests.  This
would be no different.  And the function names would be more
correct: "-at-point" would really mean at point, and the
behavior you expect would be properly named "-near-point".

This bug has been declared "minor", but it is not - it makes
the thing-at-point code unusable in a general and precise way.
The fix, however, is trivial.  The pushback from you is major.