bug#14241: 24.3; widgets and posn-at-point

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 22 Apr 2013 12:00:02 +0200
> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> 
> Running the following code in a graphical emacs
> 
> (let (oposn opoint)
>   (widget-create 'checkbox) ; point is left after the widget
>   (setq oposn (posn-at-point)
>         opoint (point))
>   (forward-char -1) ; point now at the widget
>   (message "Old: %s (Point at %d)\nNew: %s (Point at %d)"
> 	   oposn opoint
> 	   (posn-at-point) (point)))
> 
> shows that oposn and (posn-at-point) are the same but opoint and (point)
> are different.

I don't think there's a bug here.  This behavior might be surprising,
but it is entirely predictable.

The problem is that creating the checkbox widget in a GUI session puts
an overlay over 3 buffer positions, the text "[ ]".  So the buffer
position immediately preceding opoint is, for all practical purposes,
inaccessible: you cannot put point there, because Emacs will banish it
outside the overlay right away.  To see that, try this simplified
recipe:

 M-: (widget-create 'checkbox) RET
 C-x =
 M-: (forward-char -1) RET
 C-x =

See how point doesn't move?

However, the way Emacs implements this restriction is not on the
buffer level, it is on the command-loop and cursor positioning level.
So while your Lisp code runs, it "succeeds" to put point in the
forbidden area, and assigns that to opoint.  But posn-at-point
collects its data by emulating display routines, so it abides by the
rules of cursor positioning, and reports the position after the widget
regardless.  And point is moved back to after the widget once the Lisp
code is exhausted and execution returns to top level.

Any real-life code that bumps into this needs to work around this
peculiarity.  E.g., don't try forward-char to a position that is
covered by an overlay.