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

[Dmitry Gutov]

On 02/26/2016 03:44 AM, Drew Adams wrote:

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

If the thing _begins_ at point, and the third-party code in question 
calls (save-excursion (forward-char -1) (thing-at-point 'foo)), they 
will get nil.

> > Maybe there aren't too many. Will you do the research on this?
>
> Does anyone need to?

I imagine so.

> 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 never mentioned anything Eclipse-related in this bug.

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

See above.

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

If the list is at the end of the buffer, it gives me an empty string, or 
a string of spaces. So yeah, this particular "thing" seems bugged.

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

Because there is no such example.

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

Not just mine. I believe I have demonstrated that the code has been 
written with exactly this expectation in mind. And stayed like that for 
decades.