bug#35536: 27.0.50; Expose buffer's marker list to Elisp

[Eli Zaretskii <eliz@gnu.org>]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: <35536@debbugs.gnu.org>,  <maurooaranda@gmail.com>,  <monnier@iro.umontreal.ca>
> Date: Thu, 02 May 2019 17:51:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> >> Date: Thu, 02 May 2019 16:44:52 +0100
> >> Cc: Mauro Aranda <maurooaranda@gmail.com>,
> >> 	Stefan Monnier <monnier@iro.umontreal.ca>
> >> 
> >> I attach a patch implementing this based on BUF_MARKERS, as per Martin's
> >> suggestion.  Any reasons not to expose such a function?
> >
> > I'm not yet convinced we need something like that, but in any case, is
> > the order important?  Because the code you propose produces a list in
> > reverse order.
> 
> The order of the returned list is in increasing buffer position, thanks
> to the call to Fsort.  Is that not a reasonable order?

Sorry, missed the sort.  The question whether the order matters still
stands, though.

> > More generally, I think we should discuss the need for this in more
> > detail.  Markers are used for several features, and there's internal
> > stuff like conversion from character to byte positions that depends on
> > them.  Changing markers could thus easily crash Emacs, especially if
> > it comes in some in-opportune moment.
> 
> Are you saying that BUF_MARKERS could include markers created by
> internal functions which could crash if these markers are changed across
> calls to other Lisp functions?

Please don't forget that nowadays we call Lisp from many places in C,
like from redisplay.  We need to be very careful with this because I;m
quite sure the display code doesn't expect markers to change at least
in some of its paths.

> If so, that sounds like a valid concern to a non-expert like me, but it
> also sounds like a bug waiting to happen, given that other C code
> also traverses and manipulates BUF_MARKERS.

Emacs being designed using the MVC pattern, assumes that the buffers
(and thus markers) don't change while they are being displayed.  It
has some probes for when this might happen as result of calling some
hook, and when that is detected, we restart redisplay.  I'm saying
that enlarging the potential for such changes will need careful
auditing of code that didn't expect such changes until now.  It will
also necessarily slow down redisplay.  The question is: is that worth
the hassle?  If what is needed is some higher-level features, then
exposing markers to Lisp will unnecessarily force us to do all that
non-trivial auditing.  So I suggest that we discuss the needs before
coding, to see whether such low-level access to a central data
structure is really needed and justified.

> If not, I don't see how manipulating markers returned by marker-list is
> any worse than manipulating those created at the Lisp level, with the
> usual and documented risks associated with manipulating markers not
> owned by the caller.

Just reading the markers probably won't but do you really believe this
is the last word?  How many hours will it take for someone to ask for
a primitive to set the C-level markers as well, or request the ability
to map a function over all the markers?  If it's really needed, sure,
let's do it.  But is it?  Or are we doing that just because we can?

> I have yet to see a use-case for marker-list which can't be engineered
> in a different way (other than as a replacement for the obsolete
> buffer-has-markers-at, FWIW).

Well, the discussions you cited did express requirements whose
implementation with the existing facilities was either inconvenient or
restricted.  If these problems are still relevant, then why not try
providing some primitives to help them?

IOW, let me turn the table and ask: why would a Lisp program want to
get a list of all the markers in a buffer, especially those not
created from Lisp?