yes, this looks exactly right. i guess it was indeed my mistake -- my handling
of () zero-length extents was one of the last things i changed [previously i
actually changed their properties to be [) at creation time, but this caused
problems when people created closed-open extents through multiple
set-extent-property calls].
btw hrvoje it would help if you cc'd me [or perhaps more accurately, didn't
delete me from the cc list] -- i sort my mail in various ways based on headers,
and frequently don't see your mail in the obvious place.
Michael Toomim wrote:
The patch sent out by Hrvoje Niksic fixed the problem for me. I've
copied his message below.
On Thu, 5 Apr 2001, Ben Wing wrote:
> 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:
------------------------------------------------------------------------
Michael Toomim <toomim(a)OCF.Berkeley.EDU> writes:
> 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:
[...]
> 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].
I think there is a logic flaw in process_extents_for_insertion_mapper.
The second test, which is supposed to handle zero-length open-open
extents, fails to correctly handle open-closed zero-length extents.
I believe the patch appended below should fix things. It clearly
separates the legal cases that handle start-open and end-closed
correction from the aberrant open-open case.
Extents really call for an automated test. I think I'll write one.
Ben, you wrote the extent code; does this patch look good to you?
--- src/extents.c.orig Wed Apr 4 19:18:56 2001
+++ src/extents.c Wed Apr 4 19:23:10 2001
@@ -4589,12 +4589,19 @@
new_start = extent_start (extent);
new_end = extent_end (extent);
- if (indice == extent_start (extent) && extent_start_open_p (extent)
&&
- /* coerce zero-length () extents to [) */
- new_start != new_end)
+ if (indice == extent_start (extent) && extent_start_open_p (extent))
new_start += closure->length;
if (indice == extent_end (extent) && !extent_end_open_p (extent))
new_end += closure->length;
+
+ if (new_start > new_end)
+ {
+ /* coerce zero-length () extents to [) */
+#ifdef ERROR_CHECK_EXTENTS
+ assert (extent_start_open_p (extent) && extent_end_open_p (extent));
+#endif
+ new_start = new_end;
+ }
set_extent_endpoints_1 (extent, new_start, new_end);
}
--
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.