bug#38051: 26.3; (elisp) `Insertion' use of verb "point"

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

> > 1. From a user point of view (conceptual model),
> >    markers _are_ objects that can be located
> >    _in_ a buffer, _at_ buffer positions.
> 
> That is incorrect.  A marker stores a buffer and a location within
> that buffer, but it isn't itself located in a buffer.

From a user point of view.  That's the point.
That can't be "incorrect".  It's a question of
what the user needs as a conceptual model to
work with markers (and overlays, for that matter).

Does the model fit the observable behavior?  That's
something that makes sense to ask.  So far, I've
seen no example of a case where it doesn't fit.

It does not matter one whit to a user what the
implementation of a marker is.  Whether a marker
"stores a buffer and a location" or a marker
stores a (code) pointer to a buffer and a location,
or however else it might be implemented.

Unless you can show the contrary.  Ehat user-visible
behavior is unexplained by the simpler user model
I described (and which we already use for overlays,
and which we already partly - but not consistently -
use for markers)?

> > 3. When we document `char-after', we don't say
> >    that the char (which is conceptually _in_ the
> >    buffer) "points at" a buffer position.  We
> >    say "Return the character _in_ current buffer
> >    _at_ position POS."
> >
> >    Markers, like characters, are at buffer
> >    positions (chars are actually after, not at).
> 
> See above: that's correct about characters, but incorrect about
> markers.

"Incorrect" is the wrong way to talk about such
things. A user description/model that is coherent,
consistent, and complete - jibes with observable
behavior - is fine and dandy.  Useful, sufficient.
 
> > This is how we treat overlays.
> 
> Overlays are completely different beasts.

If you say so (without any explanation of why you
think so).

Does an overlay store a buffer and two locations
within that buffer?  Why is it necessary (or even
useful) for a user to think in terms of a marker
doing that but not an overlay?

What is it in the user-observable behavior of a
marker that requires introducing the extra
(I'd say extraneous) construct of it "pointing to"
a buffer and a position within that buffer?  A
construct that is nowhere defined or explicated.