RE: Overlay insertion types, markers, etc.

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

>   > 1. Why, if you pass markers [to `make-overlay],
>   >    isn't the default to use the insertion types of
>   >    those markers?
> 
> I don't think I ever thought about the question back then.
> 
> Did pointers even have insertion types, back when
> overlays were first introduced?

No idea.  I know much less than you about this.

> However, the function calling convention would have
> to be complex to give you three options: yes, no,
> or inherit from the marker.

Not sure what you mean.  We already have the
ability to specify, using optional args, the
insertion types and the buffer.

The only question is where the _defaults_ for
those come from, i.e., when you don't specify
their optional args.

Today, the defaults ignore such info from any
marker args.  Today, the current buffer is the
default buffer, and the default for insertion
is "the overlay extends to include any text
inserted at the beginning, but not text inserted
at the end".

If we instead allowed the defaults to be taken
from marker args, and if someone wanted today's
default behavior, s?he would just pass a marker
position (`marker-position') instead of the
marker itself.

And as I mentioned to Eli, if two markers are
passed and they disagree wrt such things, then
the defaulting could be done as it is now:
ignore conflicting info from the markers.

E.g., if two markers have the same buffer (or
if only one of the position args passed is a
marker), use that `marker-buffer'.  Similarly,
for FRONT-ADVANCE and REAR-ADVANCE.

And yes, such a change in defaulting would
not be backward compatible - code that passes
markers and expects the default buffer and
default insertion behavior to be as now would
break.  Users would need to update such code
to use `marker-position'.

But again, I wasn't proposing that or anything
else.  I was just trying to understand why we
do what we do.

>   > 2. Why isn't there (or is there?) a simple way to
>   >    change the "marker insertion types" of an
>   >    existing overlay?
> 
> I never thought of adding it.
> 
>   > 3. 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?
> 
> I never thought about it.
> 
>   > 4. Can you retrieve the markers that are "used by"
>   >    an overlay, i.e., as markers?
> 
> If you could get at them, you could change their buffer positions.
> I think that would mess up the overlay sort order and cause bugs.
> You could also put them in another buffer and cause even worse
> trouble.

That's what Stefan said.  See my reply to him
about that:

https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00603.html

In particular, I think it's confusing for the
doc to talk about the _markers of an overlay_
(this is not about the markers that you pass to
`make-overlay'), since they are not markers in
the usual sense of being Lisp objects (that is,
visible and accessible from Lisp).

At least it confused me and prompted my questions.

Now that I understand a bit more, I'd suggest
that the doc be changed to remove mention of an
overlay having markers (internal though they are).
That doesn't add anything, I think, and it can
confuse.

It should be enough to say that, like a marker,
an overlay has a buffer and text-insertion
behavior.  In particular, the latter means that,
by default, an overlay advances when you insert
text before it.