GNU bug report logs - #35536
27.0.50; Expose buffer's marker list to Elisp

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35536 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, maurooaranda <at> gmail.com, monnier <at> iro.umontreal.ca
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.