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

[Drew Adams]

> Isn't the safest and simplest solution to rename the current
> *-at-point to *-near-point, keep the *-at-point names as obsolete
> aliases, and add new *-precisely-at-point functions with the
> definitions from the thingatpt+ library? That way, current users of
> *-at-point who happen to be relying the on *-near-point functionality
> won't break. Only downside I can see is a slightly longer name for the
> *-precisely-at-point callers, but that doesn't seem too bad.
> 
> What you do think?

That's possible (and I appreciate your trying to find a
diplomatic way to get this bug fixed), but I don't think
that is the best approach.

We should aim to have a reasonable name, not just something
that doesn't conflict.  There is little sense in abandoning
the most reasonable name for this, IMO.  This is what the
library is intended for: returning a thing at point.

If the name "*-at-point" is kept (for behavior that is really
at point) then the worst that will happen is that some users
might complain that they no longer get a thing that is before
point but not also at point.

And that won't even happen for distributed Emacs code, which
should replace any appropriate calls to *-at by *-near (where
appropriate means that you really do want to retrieve the
thing before point as well as the thing at point).

This is a simple off-by-one bug.  It really should not require
anything to be deprecated.  Just because someone might have
gotten used to the bugged behavior is not a good reason not
to fix this bug.

If going the direction you suggest is the best compromise
that can be had, I'd suggest using the name *-at-pt instead
of *-precisely-at-point.  IOW, just change "point" to "pt".

That's not the fix I prefer, and it hurts discoverability
(matches against "point"), and it doesn't jibe with names
such as `find-file-at-point', but I think it's better than
something as artificial as *-precisely-at-point.  That name
just makes one wonder.