GNU bug report logs - #14241
24.3; widgets and posn-at-point

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Mon, 22 Apr 2013 10:05:02 UTC

Severity: minor

Found in version 24.3

Fixed in version 24.4

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 14241 <at> debbugs.gnu.org
Subject: bug#14241: 24.3; widgets and posn-at-point
Date: Mon, 22 Apr 2013 20:39:50 +0300
> Date: Mon, 22 Apr 2013 12:00:02 +0200
> From: Nicolas Richard <theonewiththeevillook <at> 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.




This bug report was last modified 12 years and 19 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.