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

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

> > I have much better-behaving list-at-point code.  It's in the
> > same file, if you are really interested.  It always returns nil
> > if the cursor is not on a list (there is no list at point),
> > including when point is at eob.
> 
> I'd be interested in a patch. Especially if it's orthogonal
> (as it should be) to whatever we decide in this bug.

I'm interested in _this_ bug being fixed.  Bugs for individual
THINGs are much more minor.  This bug affects *all* THINGs - the
basic behavior of thing at point.

This about the basic behavior.  But this is a bug that someone will
not notice if their only use of thingatpt.el is, as in your case,
to grab some text near point for completion or for use as a default
value.  That is why this bug has gone unnoticed and unreported.

Such uses underestimate the power of thingatpt.el and misunderstand
what it is about.  It is about more than trying to maximize the
possibility of getting something near point.  It is important that
the functions can actually tell you, accurately, _whether_ there is
a THING at point.  If you are looking to grab something near point
then you don't care about this.  But that's not all of what
thingatpt.el is about.

If you want to get a THING that is at OR NEAR point then you should
use code that does that (I have such *_nearest_* code, and you are
beginning to work on some too, it seems).  But thing-at-point (and
bounds) should not be corrupted to return a THING instead of nil
when there is no THING at point.  That is, alas, currently the case.

But as I said, I do not need this bug fix for myself.  I use my own
code, which does not have the bug.  I had to fix it long ago, to
get reasonable behavior for navigating among and parsing multiple
THING occurrences.  The boundary between one THING and another, and
between a THING and non-THING needs to be defined in a way that
is consistent and usable in a general way.  That's not the case
if a THING _before_ point is returned when you try to test for
a THING at point.

Likewise for users of my libraries.  I let them know that the
Isearch+ and Icicles features that act on successive THINGs in a
buffer will not work for some THINGs if they use only vanilla
thingatpt.el.  For consistent and reliable use they will need to
also load thingatpt+.el.  (My libraries do not _require_ it.)
I occasionally get a bug report to which I need to reply that
thingatpt.el has this bug and advise them to use thingatpt+.el
for things to work.

For them to take advantage of the code that really uses THINGs for
more than simply grabbing text near point to use as a default value
or for completion, this bug needs to be fixed.  Or they need to use
thingatpt+.el.  I would prefer that they be able to get the fixed
behavior from vanilla Emacs, but if not, no problem for me.
I filed the bug report for Emacs, not for me.  But you know that.