From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#46915: [PATCH] Remove unecessary change_req arg from overlays_at() Date: Thu, 04 Mar 2021 12:03:59 -0800 Message-ID: <87r1kuadow.fsf@mdeb> References: <835z27jagi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17232"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46915@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 04 21:05:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lHuDg-0004K7-2x for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Mar 2021 21:05:12 +0100 Original-Received: from localhost ([::1]:42450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHuDf-0006BC-4M for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Mar 2021 15:05:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHuDW-000682-9D for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 15:05:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48754) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHuDW-0000R3-12 for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 15:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHuDV-0008Tw-RL for bug-gnu-emacs@gnu.org; Thu, 04 Mar 2021 15:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Mar 2021 20:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46915 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46915-submit@debbugs.gnu.org id=B46915.161488825332545 (code B ref 46915); Thu, 04 Mar 2021 20:05:01 +0000 Original-Received: (at 46915) by debbugs.gnu.org; 4 Mar 2021 20:04:13 +0000 Original-Received: from localhost ([127.0.0.1]:60300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHuCj-0008Sr-3H for submit@debbugs.gnu.org; Thu, 04 Mar 2021 15:04:13 -0500 Original-Received: from relay7-d.mail.gandi.net ([217.70.183.200]:57009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHuCe-0008Sb-KN for 46915@debbugs.gnu.org; Thu, 04 Mar 2021 15:04:12 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from mdeb (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 1FDCE20006; Thu, 4 Mar 2021 20:04:01 +0000 (UTC) In-Reply-To: <835z27jagi.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201452 Archived-At: Eli Zaretskii writes: >> From: Matt Armstrong >> Date: Wed, 03 Mar 2021 18:29:28 -0800 >> >> I was scratching my head trying to figure out why overlays_at() had such >> a complex function signature. It turns out that it does not need to be >> so complex now and, I think, it never did. >> >> >From 0337e4823b32dd15bdae1f61df12b5f68170e360 Mon Sep 17 00:00:00 2001 >> From: Matt Armstrong >> Date: Wed, 3 Mar 2021 16:31:02 -0800 >> Subject: [PATCH] Remove unecessary change_req arg from overlays_at() >> >> The change_req arg was an unecessary complexity. It only changed what >> might be assigned to the *prev_ptr arg, and all callers that passed a >> non-null prev_ptr also passed a true change_req. >> >> This makes it clear that no caller desires the behavior that would >> have occurred with a non-null prev_ptr and a false change_req. >> >> For archaeologists, the above invariants appear to have been true from >> the beginning, and whatever bug fixed by the commits below need not >> have been controlled with a new boolean arg. See commits >> ac869cf715 ((overlays_at): Add CHANGE_REQ parameter, 2000-08-08) and >> 1d5f4c1de4 ((overlays_at): Only let CHANGE_REQ inhibit an assignment >> of startpos to prev when startpos == pos, 2000-10-25). > > Could you please tell what are the benefits of this change? The > signature may be complex, but it doesn't currently cause any problems, > does it? I'd prefer not to change code that is working and causes no > trouble. I do agree that changing code should serve some purpose. I have been looking at the performance problems related to overlays, mentioned in etc/TODO. I know that this has been worked on by multiple people over the years, but never successfully completed. I have seen the features/noverlay branch but have not yet convinced myself that the code there is the right thing. You could say that I am basically doing a thorough code review of that approach. I have contacted all the people who have formerly worked on this and all of them have no plans to resume their work, so there is space for me to do this. The first thing I do on a project like this is determine the functionality the current thing is providing to the rest of the system. In other words, what is its "real" API, and how does that API differ from its "advertised" API? 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.