Re: Overlay insertion types, markers, etc.

[Eli Zaretskii]

> Date: Fri, 15 Nov 2019 08:54:05 -0800 (PST)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> 
> > 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?

Because that's the minimal useful thing to do.  We do that in many
other APIs.  Anything beyond that would need a good reason.

> > > 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)?

You make a new overlay and copy whatever you want to keep from the old
one.

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

I don't know.  Probably because a need never aroused.

> 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?

We don't normally provide every possible way to do every possible
change.  Just those which are needed.

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

The design was b y Richard, so he is the only one who might remember
why he didn't go beyond what we have.

> > > 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:

Sure, there is.  But they all complicate things, whereas passing a
buffer is simple and efficient.

> > > 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?

Giving Lisp programs access to those markers will complicate related
features.  For example, the display engine currently tracks only
changes to overlays, it doesn't track changes to its markers.  Also,
having references to those markers lying around will complicate how
overlays are deleted -- currently we just delete their markers.  And
these are just results of 5 sec of thinking.

> > 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?

I don't know.  I certainly find it helpful.

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

I don't think anything potentially useful is missing.  You can do
everything you want with this stuff, albeit sometimes indirectly.

> 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?

I don't know.