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

[Basil L. Contovounesios]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I attach a patch implementing this based on BUF_MARKERS, as per Martin's
>> suggestion.  Any reasons not to expose such a function?
>
> AFAIK the main reason for such a function is so that you can implement
> "replace" functions which preserves markers better than "insert+delete"
> does, right?

AIUI, yes.

> Random thoughts:
> - I wouldn't expose a `(marker-list)` function but rather `(markers-in
>   BEG END)` so you're not bothered by unrelated markers outside of
>   the region of interest.

The patch in the OP accepts optional BEG and END arguments for the
caller's typing convenience.

> - The main problem I see is that some of the markers in BUF_MARKERS are
>   "proper" markers, while others are just the markers that we happen to
>   use in the current internal representation of overlays.
>   If you can get your hands on those markers, you might end up breaking
>   some invariants on which the C code relies (e.g. place the
>   overlay-start after the overlay-end, or in a different buffer).
> - I think the serious risks (e.g. crashes) are solvable.  E.g. there's
>   room for an additional boolean field `lisp_marker` which could be used
>   to distinguish those markers which can be safely returned (because
>   they're normal Lisp-level markers already accessible from Lisp anyway)
>   from the internal ones (such as those from overlays).
> - Then we'd probably want to discussion whether markers used within
>   `save-excursion` and friends should be marked as `lisp_marker` or not.
>
> This said, as you say later:
>> I have yet to see a use-case for marker-list which can't be engineered
>> in a different way
>
> So, whether it's worth the trouble: I don't know.

Given a sufficiently sufficient save+restore primitive as per Eli's
suggestion, it's not looking worth the trouble.

Thanks,

-- 
Basil