Zero-length extent insertion bug
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 it 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