From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.bugs Subject: bug#71370: 30.0.50; Please un-obsolete buffer-substring as a generalized variable Date: Wed, 5 Jun 2024 09:16:53 -0500 Message-ID: <2dd5d406-3185-4484-8aa8-856e5d717d48@alphapapa.net> References: <86jzj3k3nd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14307"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 71370@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 05 16:18:17 2024 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 1sErSw-0003Nx-6h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jun 2024 16:18:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sErSa-0005ey-0C; Wed, 05 Jun 2024 10:17:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sErSX-0005eV-8z for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 10:17:49 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sErSX-0006Nr-0K for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 10:17:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sErSk-0000YB-Ip for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 10:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Adam Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2024 14:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71370 X-GNU-PR-Package: emacs Original-Received: via spool by 71370-submit@debbugs.gnu.org id=B71370.17175970411988 (code B ref 71370); Wed, 05 Jun 2024 14:18:02 +0000 Original-Received: (at 71370) by debbugs.gnu.org; 5 Jun 2024 14:17:21 +0000 Original-Received: from localhost ([127.0.0.1]:38075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sErS4-0000Vz-Qx for submit@debbugs.gnu.org; Wed, 05 Jun 2024 10:17:21 -0400 Original-Received: from basenji.birch.relay.mailchannels.net ([23.83.209.12]:24985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sErRz-0000VZ-PC for 71370@debbugs.gnu.org; Wed, 05 Jun 2024 10:17:19 -0400 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D125214382B; Wed, 5 Jun 2024 14:16:55 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a254.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 738971427E1; Wed, 5 Jun 2024 14:16:55 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1717597015; a=rsa-sha256; cv=none; b=xtsvVbIp2XKPnyBaX1mfVapVvpIopNLLkbaA4Lo7+67QiAKknk+X5QwrTUlbCpS6j93N+G shVrb27/feQbzP6OyWiNojqgmT8kkK6/PHwWsxqvXBsZvV5nYfjqn70IfWlNs3XQDhmSKu H+tyY/XTpePRJIVuYD7VaM+pozkPNs+insH8ZLix7ceq+/xM7f91Q9wZWafNwcgDqsFhMq A5/kpNm0fAFhLy0PnytmqaDeF43pgBzfsxdLaB6iy3mk4ugnW1tMKib53qr+pQ4isjILoe qWJL3dQlUhaBCgNH/Xx2dWie+RjnjHCK9RoqzjmMtib537DP000XlZhiOJQVvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1717597015; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yDbmVzyOnQpql1vuXgjfsRNQjN4dxm++eVNACeK8SRo=; b=iubd7xTf2+LLxAY0nZDlPv8C0o8uNyrjM8hehOqHbK+qjQmc7kqOwZT+4L0O5dWfQYgMZt H25KK/jarg0+/Q7bWYw1AwZJqrgMb/dL1fJSq0c57ya5Hyu+YPy4JDAeKlN9VJkkHJaCnT NGyDTZ60oq/XHHATDWGSPTapfxTmfeVaMhgBb8UpOH3+2HpQaNrNUTXDUFd9AqfTqXiPdd M3ceABtpiGKrbiU7pPUVD6q12j4or5gztWsNy+gni88hLXf7Eqz9P7OTMLoxl/BJe1qZnI GpGauuNckWNjpjOA7JtJaC1MN/n0JQJ+w9GHggUsUeYjv+f2PrzFpcQgMHYIxA== ARC-Authentication-Results: i=1; rspamd-7f76976655-vnhxx; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Junk X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Lonely-Sponge: 7dd855de6a83f6fc_1717597015727_4215723785 X-MC-Loop-Signature: 1717597015727:4264184998 X-MC-Ingress-Time: 1717597015727 Original-Received: from pdx1-sub0-mail-a254.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.114.21.184 (trex/6.9.2); Wed, 05 Jun 2024 14:16:55 +0000 Original-Received: from [10.43.43.133] (unknown [193.56.116.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a254.dreamhost.com (Postfix) with ESMTPSA id 4VvTzq05G4zCT; Wed, 5 Jun 2024 07:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1717597015; bh=yDbmVzyOnQpql1vuXgjfsRNQjN4dxm++eVNACeK8SRo=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=LUkCsb+kw96c9O/SBg8WU9nuT0mFo24+Mr9BJjIgNir2znxbcveokuyWth6LV1/8y 8wBIiEYpbVJCcIxKw3a645dLipnSmV2kJ4LdDxcZLti71bx/r5JXdFWqwnuxsJX8iW 20KXyxtuc1JYPd4ysyA93DvVzv/YI7jUvI82coUFESfNhbmWTWQ0tFIx5MlQ0f7vLo fPWPOVcfsOvOGIQ0rD/8qhvB1wpzY0QKSii4q7DyT4ruhiixeuXz8E7I9uUV0Cpj2w Tp4twcCX0UWhuL4Z1wZf9CbertPUXlezzHVQp3A58ivrT82LJtlOS5HWpXJ4dvgc+t 8uecTEI7//zDg== Content-Language: en-US In-Reply-To: <86jzj3k3nd.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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286608 Archived-At: Hi Eli, On 6/5/24 06:52, Eli Zaretskii wrote: >> Date: Tue, 4 Jun 2024 20:33:13 -0500 From: Adam Porter >> >> >> Continuing with the theme of requesting the unobsoleting of some >> generalized variable forms (see [#65555] and [earlier discussion]), >> and given Eli's recently [mentioning] the upcoming cut of the Emacs >> 30 release branch, I'd like to request now that `buffer-substring' >> be unmarked as obsolete. > > I think it's too late to do this now, not without a very good > reason. Unless such a good reason emerges VSN, this will need to wait > till Emacs 31 at least. That would mean years more of unnecessary compilation warnings' annoying users when they install packages that use this form. Some of these users misunderstand them as bugs and report them to package developers, which wastes everyone's time. It also clutters lint/build logs on CI, sometimes making it impossible to have a clean linting pass (which requires the developer to manually inspect every "failed" run to see if it's just another of these warnings). >> This form makes some operations much more concise than they would >> otherwise be. For example, if one wants to update the text in a >> `magit-section' section, the code could be as simple as this: >> >> ┌──── │ (let ((inhibit-read-only t)) │ (setf (buffer-substring >> (oref (magit-current-section) start) │ (oref >> (magit-current-section) end)) │ "foobar\n")) └──── >> >> Otherwise, one would have to use `delete-region' and then >> `insert', which is more cumbersome and error-prone. > > I don't understand why it would be cumbersome, let alone > error-prone. Less convenient than using setf, yes, but "cumbersome"? > We've been doing that for decades. The alternative means having to bind positions in variables, use `goto-char' and `delete-region' and `insert' in a larger, more complex form. To me that seems much more cumbersome than this elegant GV form which is a simple way of saying, "Replace that region with these contents." > IOW, this is just a matter of convenience, nothing more. *shrug* Convenient code abstractions are easier to understand and maintain; that's why I like to use this form, and why I like to use Lisp. >> As I've mentioned in earlier discussions, the mass-marking of >> several GV forms as obsolete in commit >> 48aacbf292fbe8d4be7761f83bf87de93497df27 happened apparently >> without public discussion, as well as without checking the extent >> to which they are used outside of emacs.git. > > We don't discuss obsoletion, because it is never final. The > rationale for obsoleting those forms is explained in the log message, > so I think the implied accusation here is misplaced. It was not meant as an accusation--just a statement of fact, an observation; if I was incorrect, I'll be happy to be corrected. My point, of course, is that the marking--and creation of these new compilation warnings--happened without asking if anyone would be affected by it. >> By the way, I'd also like to request that the `point' and >> `window-point' GV forms be unobsoleted, for the same reasons. If >> it's permissible, I'd like to do so here rather than file separate >> bug reports for each of those, but if the maintainers prefer, I >> will do so. > > Let's see how many people want that now. In fairness to them, most probably don't monitor emacs-bugs and are unlikely to see this report, so I don't know if looking for replies here would be an accurate indicator of interest. > Use of those specific forms as GV was obsoleted in 48aacbf29 because > they are rarely if ever used as GV. Unless this and the other two > requests suddenly get crowds of people demanding to un-obsolete them > (probably unlikely, since where were those people for the last 2 > years?), I think Lars's decision to obsolete them is still solid. I don't understand how an apparent lack of internal use is a good reason to obsolete something useful. There are parts of Emacs that seem to get less use than these forms which are not marked obsolete. As an Elisp developer and tutor, I would like to see these forms used more frequently, both inside and outside of emacs.git. Emacs and Elisp are so large that it takes years for knowledge about new or little-known features to become widespread, and GVs in general are already a more advanced sub-topic. I feel like obsoleting these forms is hardly giving them a chance, and doing so because they aren't yet widely used is like a catch-22. --Adam