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