bug#58672: 29.0.50; [noverlay] overlays-in returns overlays for empty range

[Stefan Kangas]

Matt Armstrong <matt@rfc20.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Fix was pretty simple.  We iterate with an END range of ZV or ZV+1, then
>>> bail when node->beg gets past the 'end' we really care about.  The code
>>> was returning all nodes beginning at 'end', when it should have been
>>> skipping past the non-empty ones.
>>>
>>> It is attached and in the my/bug58672 branch at
>>> https://git.sr.ht/~matta/emacs/log/my/bug58672 in my
>>> https://git.sr.ht/~matta/emacs repo.
>>
>> Thanks, merged.
>>
>> [ I'm still trying to track down the origin of bug: the new code should
>>   not just reproduce the behavior of the old one, but it should also
>>   preserve as much of the old code as possible to avoid introducing such
>>   bugs.  ]
>
> I've just found places where the old code had special treatment for edge
> cases that weren't handled by the new 'overlays_in'.
>
> In particular, the edge cases are:
>
> a) Returning empty overlays, or not.
>
> b) Returning all overlays that *begin* at ZV iff the END passed to
> 'overlays_in' is == ZV.
>
> c) Returning the empty overlays that *begin* at ZV iff the END passed to
> 'overlays_in' is == ZV.
>
> d) Special casing retrieval based on the overlay's
> front-advance/rear-advance at a particular POS.
>
> The BEGIN arg to 'overlays_in' is the disjunction of (a) and (b).  In
> another patch I added TRAILING arg that is (b).  Yet another patch could
> have used (d) had 'overlays_in' supported it, but instead I post-process
> the resulting vector.
>
> Perhaps 'overlays_in' should instead take a filter predicate instead of
> a bunch of options.

Is there anything left to do here?