[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35536: 27.0.50; Expose buffer's marker list to Elisp
From: |
Drew Adams |
Subject: |
bug#35536: 27.0.50; Expose buffer's marker list to Elisp |
Date: |
Fri, 3 May 2019 10:31:17 -0700 (PDT) |
I don't want to belabor this, but I'll reply once
about this.
> > But as for the order of such a list: It's trivial
> > for users (any Lisp code) to sort by buffer position
> > or anything else, so why would the default order
> > be by buffer position?
>
> That is the order I would intuitively expect in any enumeration of a
> partially ordered set of buffer artifacts in a given region, unless
> otherwise stated.
>
> What other order would make sense when talking about markers within a
> given region?
I think the order that makes sense as the (only?) way
to get the set of markers (including those from C) is
an order that we cannot get otherwise. Creation order
is one such otherwise-unavailable order.
Anyone can get the buffer-position order at any time.
Or it can be provided as a function, if that's deemed
important.
> > What's _not_ available to users or Lisp code, I
> > think, is the order of marker creation or even the
> > order of last setting. I'd think that
> > marker-creation order (either direction) would be
> > a better default sort order for this, no?
>
> Perhaps when enumerating markers pointing at a single position, yes.
> But I think that ordering would make less sense when talking about
> markers within a given region. Assuming something like marker-list is
> deemed a useful addition (which is not yet clear), perhaps there should
> be two separate functions akin to overlays-in and overlays-at, with
> different sorting options and/or default policies.
It's not about what's most immediately useful for
most imagined uses of the markers in a given region.
It's about _somehow_ getting a set of markers
(wherever, whether within some buffer-position range
or not) in their order of creation (or modification).
Such relative time information is otherwise lost
completely. The markers themselves contain position
information. They do not contain time information.
Again, though, I'm not saying anything about whether
we need such a function at all. I'm just suggesting
that if we provide it it should probably provide info
that is not otherwise obtainable. Creation time is
one such bit of info.
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Eli Zaretskii, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Eli Zaretskii, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp,
Drew Adams <=
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Stefan Monnier, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Stefan Monnier, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Richard Stallman, 2019/05/04
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Mauro Aranda, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, martin rudalics, 2019/05/04
bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Stefan Monnier, 2019/05/02