The following code wraps an extent around some text and flags it like so: ->some text<- If you then delete the text you get <--> which is not what I would expect. Anybody know what's going on? XEmacs 21.4.6. (defvar ov nil) (defun add-ov (beg end) (setq ov (make-extent beg end)) (set-extent-properties ov `(face red begin-glyph ,(make-glyph "->") end-glyph ,(make-glyph "<-")))) (defun del-ov () (delete-extent ov)) (add-ov 1 11) (set-extent-property ov 'detachable nil) (delete-region 1 11) The original example used overlays, see <20020128093330.78903f25.Manuel.Serrano(a)sophia.inria.fr&gt; on xemacs-beta and just add the set-extent-property 'detachable sexp for the same results in that context. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

You should probably ping Kyle, I'm pretty sure he fixed a bug in zero-length extents (or maybe it was Hrvoje, I forget).

Hrvoje Niksic <hniksic(a)arsdigita.com&gt; writes: > I don't have a fix. Or do I? Not really, but at least I have a clue where to look at if someone is willing to investigate. redisplay.c's create_text_block() contains this code: /* If there are end glyphs, add them to the line. These are the end glyphs for the previous run of text. We add them here rather than doing them at the end of handling the previous run so that glyphs at the beginning and end of a line are handled correctly. */ else if (Dynarr_length (data.ef->end_glyphs) > 0) { *prop = add_glyph_runes (&data, END_GLYPHS); if (*prop) goto done; } /* If there are begin glyphs, add them to the line. */ else if (Dynarr_length (data.ef->begin_glyphs) > 0) { *prop = add_glyph_runes (&data, BEGIN_GLYPHS); if (*prop) goto done; } And this is our culprit. This code is in a loop that runs as long as there's something to do. It deliberately first handles the "END_GLYPHS" case and then the "BEGIN_GLYPHS" case. Therefore it's tempting to try to fix it by swapping the two. I've tried that, and it fixes the zero-length extent problem. But... But it breaks another case. Consider two adjacent extents, touching side by side: extent a extent b 12345678901234567 So, extent A is [1, 9), and extent B is [9, 17). Now imagine they had begin and end glyphs like this: [extent a] {extent b} 12345678 90123456 7 You would want this to be displayed like this: [extent a]{extent b} 12345678 90123456 7 And that's exactly how it's displayed -- and that's one case where it makes sense to process end glyphs first. After reversing the order of the two above blocks in create_text_block, you get: [extent a{]extent b} 12345678 90123456 7 There might be a simple way of solving it, but it will have to be devised by someone who actually understands the redisplay code. The only solution I can think of is to extend the "extent fragment" with some additional information about the begin/end glyph. For example, we might have a flag denoting whether the glyph belongs to a zero-length extent. That way we could first display the end-glyphs of non-zero-length extents, then the begin-glyphs of zero-length extents, then the end-glyphs of zero-length extents, and finally the end-glyphs of non-zero-length extents. (At least I believe that is the most desirable ordering.) There could be even more complex ordering based on the length of the extents ("display order" and all that), but I don't think anyone sane would want to depend on that.