Re: Bug (or doc bug) with zero-length extents?
this is definitely an xemacs bug! a zero-length extent such as that should
never ever expand when text is inserted. only [] extents do that.
i wrote the current extents code, and i'm pretty sure this worked back then, but
it's quite possible some later change broke it -- that was back in '94 i think!
i would be grateful if you could trace the code and find the problem. the
extent's endpoints should be getting changed in either adjust_extents[] or
process_extents_for_insertion_mapper[]. [the latter function actually has a
comment about zero-length closed-open extents:
/* The extent-adjustment code adjusted the extent's endpoints as if
they were markers -- endpoints at the gap (i.e. the insertion
point) go to the left of the insertion point, which is correct
for [) extents. We need to fix the other kinds of extents.
Note that both conditions below will hold for zero-length (]
extents at the gap. Zero-length () extents would get adjusted
such that their start is greater than their end; we treat them
as [) extents. This is unfortunately an inelegant part of the
extent model, but there is no way around it. */
]
this should not be hard, as there would be only one extent in the buffer and
only character insertion/deletion triggers these functions.
Michael Toomim wrote:
;;; 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
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.