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

[Dmitry Gutov]

On 02/24/2016 03:31 AM, Drew Adams wrote:

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

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

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

> Tell such folks to use that.  Likewise, add `thing-at-or-after-point',
> if necessary, for any code that current depends on the broken
> `thing-at-point'.

Won't be usable in packages targeting older versions.

I'm not saying it's entirely out of the question, but personally, I'm 
not convinced.

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

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

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

> > They can call (bounds-of-thing-at-point 'foo), and then compare
> > the cdr with the value of point.
>
> You are missing the point.  I won't repeat myself.

Thanks for that.

> Look at `goto-char' or any other char-counting functions.  If you
> move point "to" character 2, point = 2.  The char "at" point is the
> char after point - point is before the char that has the same number
> as point.  When point = 2 the cursor position (aka point) is between
> chars 1 and 2, and we say point is "at" (or "looking at") char 2.

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

> Believe me, I've walked through that particular code a hundred
> times, in the debugger and without.  The code you are referring
> to is needed, and it is not about finding a thing that ends before
> point.

Even though the comment says that.

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