bug#28390: 26.0.50; overlays-at actually sorts by increating priority

[Eli Zaretskii <eliz@gnu.org>]

> From: joaotavora@gmail.com (João Távora)
> Cc: 28390@debbugs.gnu.org,  monnier@iro.umontreal.ca
> Date: Fri, 08 Sep 2017 09:57:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think the doc string says what the implementation was supposed to
> > do, so we need to change the implementation instead.
> 
> Really? Won't that ripple very paintuflly across the elisp ecosphere?

I don't think so.  I believe this optional argument is used very
rarely.

> > If you look at the changeset where the SORTED argument was introduced,
> > you will see that the old code sorted the list returned by overlays-at
> > in descending order of priorities, i.e. overlays with the largest
> > priority first.  It used 'sort' like this:
> >
> >   (sort (mapcar #'overlay-properties (overlays-at p))
> >         (lambda (A B) (> (or (cadr (memq 'priority A)) 0)
> >                     (or (cadr (memq 'priority B)) 0)))))
> 
> I don't follow, where is the code that did this, or is this just an
> illustration?

This is the code which was replaced when overlays-at got its optional
argument in that Stefan's change.

> > The doc string of 'sort' says that its PREDICATE function should
> > return non-nil if the first element passed to PREDICATE should sort
> > _before_ the second.  And the predicate above uses '>'.
> 
> But where was sort() ever used before Stefan's 2014 change? Did
> overlays-at make any sort guarantee back then?

Look at the changeset of commit 20fa59a0, you will see that the uses
if 'sort' were replaced with calls to overlays-at with the new
optional argument.

> I do agree that it should sort the other way, though. But it's too late
> for that, bugs will be features :-).

I'm not sure it's too late.