Re: make-overlay and endpoints

Hi Stephen

"Stephen J. Turnbull" <[email protected]> writes:

> Marcus Harnisch writes:
>
> AFAIK, Emacs doesn't give you the choice of removing the overlay from
> the buffer.
>
>  > 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.

>  > “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.

> 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

_______________________________________________
XEmacs-Beta mailing list
[email protected]
http://lists.xemacs.org/mailman/listinfo/xemacs-beta