Marcus Harnisch writes:
However, when creating an overlay in Emacs that has identical start
and end positions and the default endpoint properties, then
deleting characters at that position does not delete the overlay.
AFAIK, Emacs doesn't give you the choice of removing the overlay from
In XEmacs 21.5.34 doing the same with an extent
(start-closed/end-open) removes the extent from the buffer.
By default, and it doesn't delete the extent, it detaches it. (I
don't think Emacs implements detached overlays.) If you want the
extent to remain in the buffer, set the detachable property to nil.
If you're using the overlay library from fsf-compat, this might be a
bug in overlay emulation.
“Deletion of a character on a side of a zero-length extent whose
corresponding endpoint is closed causes the extent to be detached if
its `detachable' property is set; if the corresponding endpoint is
open, the extent remains in the buffer, moving as necessary.”
What exactly does “a character on a side” mean. I can only delete a
character “at” the extent.
You may misunderstand the nature of character positions in Emacsen, I
suspect. They are conceptually *between* characters in the buffer, so
there are two sides, before and after. Thus inserting a character
*at* a position has unambiguous semantics. This is also reflected in
the character access functions: to examine a single character you can
use `char-after' or `char-before', but there is no `char-at' function.
Extents, on the other hand, *can* be "at" a position. In particular,
a zero-length extent is "at" exactly one position (unless detached, in
which case it is nowhere). `delete-char' is an historical misnomer;
it really should be `delete-forward-char' (the reverse function is
`delete-backward-char', or maybe more easily understood would be
I'm not sure why those particular semantics for deletion of
zero-length extents were chosen, and the documentation is hardly clear
I don't understand what the practical problem you're experiencing is,
so I doubt all this theoretical discussion is of much help (unless
maybe it will result in a bug report on fsf-compat). Sorry about
that, and feel free to follow up.
XEmacs-Beta mailing list