bug#46915: [PATCH] Remove unecessary change_req arg from overlays_at()

[Matt Armstrong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> Cc: 46915@debbugs.gnu.org
>> Date: Thu, 04 Mar 2021 12:03:59 -0800
>> 
>> So, the benefit of this change can be summarized:
>> 
>>  - We don't think the current overlay implementation is necessarily the
>>    right thing, so we can presume that this area will change at some
>>    point.
>> 
>>  - If we simplify the API, future changes will be easier to review.  In
>>    particular, nobody will ever have to think about callers that want a
>>    *PREV_PTR value with a false CHANGE_REQ, and no future implementer
>>    will feel like they need to provide that functionality.
>
> I'm okay with doing this nad similar changes as part of landing the
> noverlay branch (or as part of some other similar redesign of how
> overlays work in Emacs).  What I'd like to avoid is installing this
> change separately, as if it alone has enough merit.  if the goal is to
> replace the current implementation with a more efficient one, that's a
> good change, and API simplifications could very well come with it.
> But not without it and not ahead of it.
>
> It's a bit like fixing whitespace: we don't like doing it in separate
> changesets, but together with other significant changes in the same
> area of the code.
>
> So I urge you to continue the work on the noverlay branch, and if that
> branch will come with this and other changes in the internal APIs,
> that's fine by me.  My problem is only with installing API changes
> right now, when we are not at all sure yet the overlays redesign will
> indeed land any time soon.
>
> OK?

I'm happy to defer this for now.

I might come back and ask that this change go in before doing actual
surgery on the overlay implementation.  In the past, on other projects,
I have found it worthwhile to first simplify APIs, and assert various
assumed invariants more rigidly, and let those changes bake for a while,
before beginning to modify implementations.  But, I would agree that
those kinds of changes are best done according to some sort of generally
agreed upon plan, not just ad hoc.