bug#18504: 24.3.93; posn-at-point intermittently returns wrong value for a valid buffer position

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 19 Sep 2014 23:33:58 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 18504@debbugs.gnu.org
> 
> posn at nil #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (9 . 18))
> posn at nil #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> foofoo
> foo
> posn at 195 #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> posn at 195 #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> <...>
> foofoo
> foo
> posn at nil #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> posn at nil #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> foofoo
> foo
> posn at 195 #1 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> posn at 195 #2 (#<window 16 on *scratch*> 206 (0 . 270) 0 nil 206 (0 . 
> 15) nil (0 . 0) (0 . 0))
> <...>
> 
> Point is indeed at 195. Note that the last element is sometimes 
> different between `posn-at-point' invocations ((9 . 18) vs (0 . 0)), but 
> sometimes not (both pairs of zeros)).

This happens when posn-at-point is called with the company-mode
overlay still (or already?) in place at that position.  That overlay
has the invisible property, so it hides the buffer text starting at
the position with which you call posn-at-point.  Therefore,
posn-at-point returns information about the first visible buffer
position after the overlay string.

So I think you need to make sure inside company--col-row that the
overlay is popped down, before you call posn-at-point.  Evidently, in
some scenarios it isn't.  The buffer position returned by
posn-at-point can serve as your control variable: if it is different
from the position that is the argument to company--col-row, you have
this situation.