Re: Bug (or doc bug) with zero-length extents?

;;; Note: I posted the following message a couple of days ago, but had an ;;; invalid return address and so haven't recieved a reply. My apologies ;;; go out to anyone who had mailed me an answer in vain! I have noticed xemacs' behaviour to be inconsistent with the documentation, when inserting text onto certain zero-length extents. According to the info xemacs lisp reference and comments in extents.c, insertion at a zero-length extent with the properties start-open and end-closed (like the extent (5, 5]) should go before the extent: ---- extents.c: "Insertion at the position of a zero-length extent ... goes before the extent if it is open-closed." Info - extent endpoints: "Insertion at the position of a zero-length extent ... goes before the extent if it has the `start-open' property " ---- Thus, for the above extent, if one inserts the text "###" at position 5 in the buffer, the documentation implies that the extent would change to (8, 8]. This doesn't happen. With xemacs version 21.1, patches 12 and 9, the extent instead expands to include the inserted text (like the extent [5, 5] does) -- causing the extent to change to (5, 8]. The following e-lisp code, according to the documentation, should insert "1234###56789" into the buffer, un-colored, with a zero-length extent before the 5. Instead, it creates an extent covering the "###", making those characters green. (save-excursion (goto-char 1) (insert "123456789\n") (let ((ext (make-extent 5 5))) (set-extent-properties ext '(start-open t end-closed t face green)) (goto-char 5) (insert "###") (message "The extent is now %S" ext))) The more recent stable versions of xemacs don't seem to mention any fixes of this nature. Can anyone verify this on a new release? Is this a true xemacs bug (or a documentation bug?)? Thank you, Michael Toomim