RE: Overlay insertion types, markers, etc.

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

Thanks very much for answering.  I have a few
follow-up questions, for clarity.  I don't expect
to belabor this, but things are still not very
clear to me.

> > Why, if you pass markers, isn't the default to use
> > the insertion types of those markers?
> 
> Because the markers passed to make-overlay are treated
> only as representing buffer positions, similarly to
> other functions, like goto-char.

But _why_ are they used only for their positions?
That's the question.

Functions like `goto-char' have no use of the other
information (buffer, insertion types) in a marker,
besides its position.  An overlay does have an
associated buffer and insertion types.

(I suppose someone might suggest that `goto-char'
could go to a marker in another buffer, and that
it could accept an optional BUFFER arg.  But I
haven't done that.  In any case, surely it could
have no use for an insertion type, right?)

Why doesn't `make-overlay' get the defaults for
such things from its input markers?

> > 2. `make-overlay' seems to be the only way to specify
> > the insertion types for an overlay.  Is that right,
> > or did I miss something?
> 
> That's right.
> 
> > Why isn't there (or is there?) a simple way to
> > change the "marker insertion types" of an existing
> > overlay?
> 
> Because it's easy to do that by hand?

How so?  How do you change the insertion types of
an _existing_ overlay (by hand or otherwise)?
I don't see that possibility.  And below you seem
to point to using C (?).  I'm asking whether (and
if so how) you can do this with Lisp.

> > Suppose you want to copy an existing overlay and
> > then change some things in the copy.  You can't
> > change the insertion types for it, right?
> >
> > I guess you need to use `make-overlay', specifying
> > insertion types, and then explicitly copy everything
> > else from the first overlay.  Is that right?
> 
> Yes.

Is there a good reason not to provide a way to
change insertion types in an existing overlay?

(Assuming there is no such way - see above: not
clear to me what doing so "by hand" means, i.e.,
how to do it.)

You can change overlay properties of an existing
overlay. And you can change its limits
(`move-overlay').  But you can't change its
insertion types or its buffer (or can you?).
Why not provide a way to do that?

Wouldn't it be useful to even have setter
functions for an overlay, which correspond to the
getter functions (`overlay-start', `overlay-end',
`overlay-buffer')?  Or even be able to use `setf'
with such getters?

I'm not so much proposing a change.  To start
with, I really want to understand the design and
its logic.

> > 3. Similarly, the default BUFFER for `make-overlay'
> > is the current buffer, even if you pass markers.
> >
> > Third question (similar to the first):
> >
> > Why, if you pass markers to `make-overlay', and
> > you don't pass arg BUFFER, isn't the default to
> > use the buffer of those markers?
> 
> Because that just complicates the implementation with no real gain:
> what to do if the markers point to different buffers, or if their
> buffers don't exist, or the position information doesn't fit, etc.?

(This is about determining the _default_ buffer
value, when the BUFFER arg is not provided.)

There are various possibilities (design choices).
Off the top of my head, naively:

One obvious possibility is to just do what we do
now, if the markers don't provide usable buffer
info: use the current buffer.

If the markers point to different buffers, for
example, just ignore those buffers - just do what
we do now (use current buffer).

If one limit passed to `make-overlay' is a marker
and the other is a number, use the buffer of the
marker.

If a marker has no buffer then it also has no
position, no?  How could it not?  So I don't get
your question "if their buffers don't exist".

If a marker has a position then that position must
"fit" its buffer, no?  How could it not?  So I don't
get your question "if the position information
doesn't fit".

But again, if for some reason the info from a marker
isn't usable, then just don't use it - do what we
do now.

> > 4. (Repeating) "An overlay uses markers to record
> > its beginning and end."
> >
> > It seems that an overlay "uses markers" but those
> > aren't the markers you passed to `make-overlay'.
> > Is that right?
> 
> Yes.
> 
> > Can you retrieve the markers that are "used by"
> > an overlay, i.e., as markers?
> 
> No.  We don't want to give Lisp access to those markers,
> as that could mean giving to long a rope to Lisp programs
> to hang themselves.

I don't see what the problem is.  They're just
markers (presumably).  Any code can use any marker
to hang to hang itself now.  How is that related to
the fact that an overlay would use such a marker?

> > "This is the only valid way to change the endpoints
> > of an overlay.  Do not try modifying the markers in
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > the overlay by hand, as that fails to update other
> > vital data structures and can cause some overlays
> > to be lost."
> >
> > That makes me wonder.  I don't even see how you
> > could try to "modify the markers of the overlay"
> > (with Lisp).
> 
> I believe that remark is for C programming.

So in the Elisp manual we tell users not to try
to use C to modify the markers in an overlay
"by hand"?

Why is such a remark appropriate/helpful?  How
would a reader even guess that C programming is
what that remark has in mind?
___

Please note: I have nothing particular in mind
here - no agenda.  I'm trying to understand what
the case is, and why.

Depending on the "why" (once I understand it),
if it seems weak then I may also wonder "why not"
do something more helpful/useful.

So far, that's what I'm wondering about things
like obtaining the insertion types and buffer
from the markers used to define an overlay.

But I have no special use case in mind.  It just
seems (so far) like something useful is missing.

I'm guessing that I'm wrong about this, just
because I don't yet understand enough why things
are the way they are.  Is this maybe just a case
of no one ever getting around to improve it, or
are there good reasons why things are the way
they are?