make-overlay and endpoints

[Marcus Harnisch]

Hi all

I have encountered an issue with respect to compatibility between
Emacs overlays and our extents. Here's what the GNU Emacs List
Reference Manual says:

“The arguments front-advance and rear-advance specify the marker
insertion type for the start of the overlay and for the end of the
overlay, respectively. See Marker Insertion Types. If they are both
nil, the default, then the overlay extends to include any text
inserted at the beginning, but not text inserted at the end.”

This appears to be the same as with extents.

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.

In XEmacs 21.5.34 doing the same with an extent
(start-closed/end-open) removes the extent from the buffer.

“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. In which case the start-closed seems to
have a higher priority.

In the case at hand this is easy enough to work around, but I am
wondering if that difference is deliberate, whether it may make sense
to change the behavior or whether to tell authors to not rely on
either behavior since it is a nasty corner case scenario anyway.

Thanks
Marcus

[Stephen J. Turnbull]

Post by Marcus Harnisch
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
the buffer.

Post by Marcus Harnisch
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.

Post by Marcus Harnisch
“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
`delete-char-{forward,backward}').

I'm not sure why those particular semantics for deletion of
zero-length extents were chosen, and the documentation is hardly clear
to me.

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.

[Marcus Harnisch]

Hi Stephen

Post by Stephen J. Turnbull
AFAIK, Emacs doesn't give you the choice of removing the overlay from
the buffer.

Post by Marcus Harnisch
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.

Regarding a potential issue in the overlay emulation I can look into
that. Thanks.

Post by Stephen J. Turnbull

Post by Marcus Harnisch
“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.

Not at all. I just found it very confusing that instead of using a
common "before pos"/"after pos", a rather more colloquial term was
used.

Post by Stephen J. Turnbull
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.

The practical problem is in the latest (ca 2012) version of psvn.el
which rightfully claims that #'svn-status-blame wouldn't work for
XEmacs. In contrast to the suspected (by its author) reason, it
happens that a zero-length extent is created at point (via
make-overlay), followed by #'delete-region starting at point. In
XEmacs the extent (and its begin-glyph) disappear. Presumably in Emacs
the corresponding overlay remains visible.

Swapping the two lines of code in psvn.el is trivial, but since the
existing code is meant to work in Emacs I figured this may point to a
compatibility issue.

Regards
Marcus

[Stephen J. Turnbull]

Post by Marcus Harnisch
Not at all. I just found it very confusing that instead of using a
common "before pos"/"after pos", a rather more colloquial term was
used.

Using "if before then ... if after then ..." would require a fourfold
repetition for each combination of open and closed, most likely.

Post by Marcus Harnisch
The practical problem is in the latest (ca 2012) version of psvn.el
which rightfully claims that #'svn-status-blame wouldn't work for
XEmacs.

Ah, thanks for the explanation. I know nothing about the internals of
psvn.el, let me know if I can help though.