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

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

On 23.02.2016 07:37, Drew Adams wrote:
>> I'm not sure it should be fixed. Your reasoning seems valid,
>> however by now this behavior is ingrained into my expectations
>> of how thing-at-point should behave.
>>
>> This would be a breaking change. For instance, it will make
>> (bounds-of-thing-at-point 'symbol) unsuitable for use in a
>> completion-at-point-functions element,
> Why do you think so?  Have you tried it?  It does not affect
> the behavior for THING = `symbol' at all.
>
>> to compute the first two values of the returned list, because
>> during completion you're most often "after" the symbol.
> So?  Not a problem.  Put point after a symbol - you get the
> same answer as now.
>
>> And I do use it for that purpose in one third-party package.
>>
>> emacs-eclim also uses it in
>> eclim-java-show-documentation-for-current-element. At the
>> very least, this will change the existing behavior.
> This is the design of the thingatpt code, and the reason why
> `<=' instead of `<' is a bug:
>
>    the function that is (get THING 'end-op) moves PAST the THING,
>    so that point is not on the THING.  This is true generally, no
>    matter the type of THING.
>
>
>


That what I changed at

https://github.com/andreas-roehler/thing-at-point-utils

ar-forward-list-atpt would stop at closing paren, not one char after as 
forward-sexp would do.

Char after FORM in not considered inside in sense of at-point.