From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#71370: 30.0.50; Please un-obsolete buffer-substring as a generalized variable Date: Sat, 22 Jun 2024 06:05:10 +0000 Message-ID: <874j9lo6ll.fsf@localhost> References: <87iky4zedz.fsf@web.de> <545868c6-1a14-4a3f-9939-da2477c0a902@alphapapa.net> <871q4reij4.fsf@web.de> <87le2z7h37.fsf@localhost> <87ed8pnc1w.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7759"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Porter , 71370@debbugs.gnu.org, Andrea Corallo To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 22 08:04:38 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 1sKtrZ-0001kM-Mf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jun 2024 08:04:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKtr5-0004Mc-0S; Sat, 22 Jun 2024 02:04:07 -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 1sKtr1-0004MH-4N for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 02:04:03 -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 1sKtr0-00045N-SM for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 02:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKtr0-0004He-4k for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 02:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jun 2024 06:04: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.171903622316444 (code B ref 71370); Sat, 22 Jun 2024 06:04:02 +0000 Original-Received: (at 71370) by debbugs.gnu.org; 22 Jun 2024 06:03:43 +0000 Original-Received: from localhost ([127.0.0.1]:44144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKtqg-0004HA-I7 for submit@debbugs.gnu.org; Sat, 22 Jun 2024 02:03:42 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:56945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKtqc-0004Gu-Lc for 71370@debbugs.gnu.org; Sat, 22 Jun 2024 02:03:40 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D78F1240027 for <71370@debbugs.gnu.org>; Sat, 22 Jun 2024 08:03:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719036212; bh=KWbPVO93nCe59KKFbTWzGab/VpLURc0DYvLHSv3jyu0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Or2D2ILJMcptvOG2T1eyBDThA9vnj3DHHifBnecAHmQ8RIiHz8oZicJThqGFoOJXC yVN9t9uekhmTOrcnufwDBwtwHOQQyz81PWQBKQOo/FH1nLo/h/PpJzGn8zZoHg1Z93 naYrUWjzBd+hae15OTg7J7UcZV8aJw1jvCxE0KtJC7uCDRggf4mc0XUvrpuLt3vaMH mwlPFo1RcsXb2ENPQSUg1VUerblcMZWoDhc8RE4E6ulytsDm42yX2x0NtqC+riqvYW nBUARS5wPSRfIYAipySsOMzBq03pnzoM3/TunHFhOfxg1EBlb6G09qijCRTIcrtS+P QXqEG2njW0BJQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W5kDg31zHz9rxF; Sat, 22 Jun 2024 08:03:31 +0200 (CEST) In-Reply-To: <87ed8pnc1w.fsf@web.de> 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:287651 Archived-At: Michael Heerdegen writes: >> While some of them are rarely/not used some others looks quite popular. >> This is an indication that the popular ones are probably a good >> abstraction or they are just convenient. > > More of the latter I would say. Nonetheless that's one aspect that > counts. > > But especially `buffer-substring' doesn't convince me as a gv because > semantics are very doubtful: > ... > These were exactly the kind of problems why those place expressions had > been obsoleted. Do note that the original reason of obsoletion was different: 48aacbf292fbe8d4be7761f83bf87de93497df27 Make many seldom-used generalized variables obsolete The vast majority of these are unused in-tree, and many of them perform actions that aren't obvious when reading the code. No arguments have been listed about "actions that aren't obvious" wrt `buffer-substring' generalized variable. And, as we see, "unused" is only true for Emacs sources, but not for third-party libs. > - You say (setf (buffer-substring START END) STRING). The first thing > that is not crystal clear is the question whether STRING will be > added, or will replace, existing text. > > - The END argument is either redundant, or, if text is replaced (which > is what the current implementation does), it is unclear what happens > if STRING has a length different from (- END START). The current > implementation doesn't even fulfill the most _basic_ assumption about > places: if STRING has a different length, after > (setf (buffer-substring START END) STRING), > (buffer-substring START END) will _not_ be equal to STRING. This is > very bad, conceptually. > > - For this reason resetting the place to the old "value" will not > always restore the old situation. > > - With `cl-letf' the generalized variable gets even more doubtful: if > you edit the buffer contents inside the scope of the binding, > reverting a `buffer-substring' gv binding will give surprising > results, especially if START and END were specified as integers then > pointing to unrelated positions. FYI, I never had this kind of confusion. It is perfectly expected for _buffers_ that any kind of modification may render point positions inaccurate. If one needs to track specific region even when modifications are performed, this is what markers are for. And markers do work when used as arguments for buffer-substring. > ... Adding a little helper function with clear semantics > really looks more appropriate in this case in my opinion, even if you > have to remember one more name. Maybe. But I would argue that `buffer-substring' is already _the most popular_ among obsoleted generized variables. Clearly, people do find it useful; and, clearly, obsoleting it forces many library authors to do extra work that is not justified. I would be ok with adding a helper _in addition_ to generalized variable, but I do not see it justified to make it replace it (at least, not until we see that the added new helper is vastly more popular) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at