RE: Overlay insertion types, markers, etc.

[Drew Adams <drew.adams@oracle.com>]

> > 4. Can you retrieve the markers that are "used by"
> >    an overlay, i.e., as markers?
> 
> No, you can't, and you shouldn't be able to: it's
> an implementation detail, that may change in the
> future (IIUC the `noverlays` branch indeed makes
> this change as part of a rewrite which tries to
> eliminate some algorithmic complexity problems in
> the overlay code).

OK.  The other questions I asked were about using
the markers passed to `make-overlay' to specify the
_defaults_ for the overlay: insertion types and
buffer.  That is, the values to use for those if
the optional args to specify them aren't provided.

Those other questions were not about the markers in
the overlay itself - they were only about obtaining
default info when creating an overlay and passing
it markers instead of numbers.

This question (#4) was different.  It was about
Lisp access to the markers used in the overlay
itself.  About which nothing is said, BTW.  But Eli
has confirmed that they are indeed markers.

"Marker" in the Elisp doc (other than here) means
an object accessible from Lisp.  It's confusing
to talk, in passing - with no description or
explanation, of "markers" that are used by an
overlay (i.e., as part of it), but that are
(it turns out) not markers in the usual sense,
because they're not accessible to Lisp.

It confused me anyway.  All the more so because
the doc doesn't actually say they're only internal,
not accessible.

Hence this question (#4), to find out if they are
in fact somehow accessible.

> Also it would introduce all kinds of extra work:
> - when an overlay is moved, the redisplay code is
>   told about it, whereas no redisplay is normally
>   caused by moving a marker, so we'd need to figure
>   out what to do when an "overlay-owned" marker is
>   moved.

I'm not proposing anything.  But I'm guessing that
that point is incorrect in one sense (one direction).

If the overlay does, as the doc and Eli say, use
markers, then when the overlay is moved those
markers are presumably already updated accordingly.

But there's also the reverse, which you bring up:
moving the markers.  You segue to moving (e.g. by
Lisp) one or both of the overlay markers.

> - the user could now move the start-marker of an
>   overlay to another buffer than the end-marker
> - the user could now move the end-marker of an
>   overlay before the start-marker (this can already
>   happen but only in very specific cases, so we'd
>   have to handle it in more cases).

Those are cases of not only examining the markers
from Lisp but changing them.

There is already a (mysterious, IMO, since the
markers are currently internal) warning in the
Elisp manual _not to do_ that:

  "Do not try modifying the markers in the
   overlay by hand..."

(Eli has said that that warning must be to not
try that using C code.  Why such a warning would
be in the Elisp manual is not clear to me.)

But suppose the markers were modifiable from Lisp,
and suppose someone ignored the warning.  The
result could (by design) simply be to delete the
overlay.  IOW, if an overlay for any reason has
markers that are nonsensical (for an overlay) then
treat it as deleted (no buffer).  One possibility.

Again, I didn't propose providing Lisp access.
I was asking why we tell users that an overlay
has markers, instead of, for example, just saying
that it has a start, an end, and a buffer?  Why
talk about the "markers" of an overlay at all?

Especially since they apparently are not markers
in the usual sense (Lisp objects).

We don't use markers passed as `make-overlay'
args for anything but initializing the start and
end positions (presumably swapping them, if
passed in the wrong order numerically).

What's the point of documenting that an overlay
has markers?  And not saying clearly that they're
only internal - not normal markers (i.e.,
Lisp-accessible)?  And warning users not to
modify them - which they can't do anyway using
Lisp.

It's the doc that led me to ask these questions.

I haven't proposed any changes to the behavior -
or even to the doc.  But given the answers to my
questions so far, it seems to me (assuming that
no behavior changes are in order or desired),
that the doc should maybe be changed a bit.  No?

---

BTW, you mention "the `noverlays` branch indeed
makes this change as part of a rewrite which tries
to eliminate some algorithmic complexity problems
in the overlay code."

What's that about?  Is there a plan to remove
overlays?  It would be good to know this, so we
(e.g. 3rd-party code) don't waste time developing
things that depend more on overlays.