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

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

> So I think the conclusion here is that we don't want to change the
> behaviour, and I'm therefore closing this bug report.


This is extremely unfortunate.  Quite misguided.

This completely misunderstands and misses the
point of `thingatpt.el' - in particular of
`bounds-of-thing-at-point'.

The point is NOT simply to try to obtain a
thing (and its bounds) _near_ point.

The aims and use cases (there are two) are:

1. To find out _whether there is_, in fact,
   a THING at point.

   AT POINT - not point OR (point - 1).

2. IF there really is a THING at point, to
   return it (or its bounds).

This bug is about the misguided behavior that
returns the THING at (point - 1) instead of
returning nil, when there's NO THING at point.

This bug renders thingatpt.el useless for any
functionality that needs to know _whether_
there's a THING at point.  And that means a
loss of lots of use cases - down the drain.

The miscoding is motivated by an expectation
that the only thing anyone ever wants to use
thingatpt.el for is to get a THING near point
for use as a default value for reading input.

That's the least useful application of thing
at point.  (It's a common one, admittedly.)
___

It's possible to define other functions that
do have as their only aim to return a THING
that's NEAR point.

As mentioned in the bug thread, it's not hard
to do that , and even to let callers specify
a tolerance that defines NEAR.  Such a function
is really what should be used to get some
default text for reading minibuffer input.
(I've offered this - code.)

But a get-some-THING-near-point functionality
doesn't in any way _replace_ the need for aims
1 and 2 of the thingatpt.el design.  The code
is corrupted, resulting in loss of the raison
d'etre for thingatpt.el.

A new low for Emacs.