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

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

> > The fix to your code and theirs is trivial.
> 
> Where's that "think of the poor users" call of yours that
> accompanies any breaking change in Emacs? Users don't like broken code.
> We can only fix code inside Emacs.

And when we do, 3rd-party code sometimes has to adjust.  I'm forced
to do that all the time - and not for bug fixes, usually.

This fix will give all users better, and consistent behavior.

> > Bit if you must, rename the current, bugged implementation of
> > `bounds-of-thing-at-point' to `bounds-of-thing-at-or-after-point'.

I meant ...-or-before-... not ...-or-after-...

> A rename will break third-party code just as well.

The proper fix for such bad 3rd-party code (it never should have
depended on a bug that nil is not returned when there is no thing
at point) is to move to the position where it _really_ wants to look
for a thing.  Such code is typically just looking for a thing near
point, for completion or to use as a default value.

But we _could_ provide a function that finds the thing at or just
before point.  If you don't want to provide such a function, so
much the better.

> > Tell such folks to use that.  Likewise, add `thing-at-or-after-
> > point',

(Again, I meant ...-or-before-... not ...-or-after-...)

> > if necessary, for any code that current depends on the broken
> > `thing-at-point'.
> 
> Won't be usable in packages targeting older versions.

Right.  Like all 3rd-party code, it will use (if (fboundp...)...).

But the proper fix for 3rd-party code, mentioned above, does not
have any such problem.  It should look for a thing at (1- (point))
if it wants to get a thing that might be just before point but not
at point.

That's what always should have done, and that has always worked
(and hopefully always will).

> > If you must, do that plus deprecate the (perfectly good, but not
> > for this broken code) name `bounds-of-thing-at-point', so any such
> > 3rd-party code makes the change.
> >
> > And add a function `bounds-of-thing-at-point-strict' that does
> > what `bounds-of-thing-at-point' should do (= the bug fix).  Change
> > the Emacs code that uses the broken `bounds-of-thing-at-point' to
> > use `bounds-of-thing-at-point-strict'.
> 
> We can add bounds-of-thing-at-point-strict even without changing the
> existing function. Patch welcome, I think.

It's the same patch.  The proper name for it is
`bounds-of-thing-at-point'.  But if you are stubborn then go for
`bounds-of-thing-at-point-strict'.  But be sure to use it everywhere
in the Emacs code in place of `bounds-of-thing-at-point' - that's the fix.

> > This is if you are convinced that there are zillions of uses of
> > the bugged `bounds-of-thing-at-point' that depend on the bugged
> > behavior.  I'm not convinced of that.
> 
> Maybe there aren't too many. Will you do the research on this?

Nope.  Will you?  Does anyone need to?  You're the one who
mentioned that your code depends on checking for a thing at the
wrong position in order to get a thing at point-minus-one.  And
you mentioned an Eclipse function that acts similarly.  That's two.

> > I'd say bite the bullet: fix the bug properly, and when anyone
> > complains tell them to use `bounds-of-thing-at-or-after-point'

(Again, I meant ...-or-before-... not ...-or-after-...)

> > if they really want the bugged behavior.  Better: tell them
> > to use the fixed `bounds-of-thing-at-point' after backing up
> > so point is actually on the THING instead of after it.
> 
> Any such client would be forced to call bounds-of-thing-at-point-
> strict twice. Which is not particularly ideal.

Not at all.  Why do you say that?  That's the behavior you get
today, and apparently the behavior you still want: ask for a thing
that is either at point or one char before point.

> Yup. But when we say "word X ends at position P", P is after the
> last character of X, not before.
> 
> > Before is not at (= after).  Ends at ORIG does not mean ends
> > before ORIG.
> 
> Think of the semantics of `match-end', or the last argument of
> `substring'.

Think of all the other uses of thing-at-point, and the other THINGs
it finds and where it finds them.

Type (foo bar) at top level, and put point after the ).
M-: (thing-at-point 'list)
What do you get?  id it give you "(foo bar)"?  Or did it give
you nil?  There is no list at point.  Is this a bug?  No; it's TRT.

There is a reason for this behavior.  It is what's needed when you
use `thing-at-point' in combination (e.g. repetitively).  I pointed
you to code that does this.  And yes, it needs to work for all types
of THINGs, including, yes, symbols (words, names,...).

> > But I think you either try to see or you don't.  I cannot make
> > you see.
> 
> That's a very zen position for someone who just wrote a 2.5 screen
> email. Why don't you present a valid (in your sense) configuration
> that a bounds-of-thing-at-point implementation without the "else"
> branch will return nil in?

OK, I give up.  I don't need this bug fix for my own code.  Just
trying to do a good deed for Emacs and its users.  I fixed this
long ago for myself, and I make heavy use of the fix.  You're not
interested in fixing this in Emacs.  So be it.

You said at the outset:

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

It's clearly not about your being unconvinced that the fix is correct.
It's about your not wanting to give up your ingrained expectations
of the incorrect behavior.  Sheesh.