From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Improve `replace-regexp-in-string' ergonomics? Date: Wed, 13 Oct 2021 10:57:45 +0300 Organization: LINKOV.NET Message-ID: <8735p5z79i.fsf@mail.linkov.net> References: <878rzpw7jo.fsf@gnus.org> <875yuban9b.fsf@mail.linkov.net> <871r4qalit.fsf@mail.linkov.net> <87h7dme953.fsf@gnus.org> <87r1cqct4f.fsf@gnus.org> <87ily2v04e.fsf@posteo.net> <874k9m835c.fsf@mail.linkov.net> <87y26y7yxz.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26172"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: Lars Ingebrigtsen , Stefan Monnier , emacs-devel@gnu.org To: Thierry Volpiatto Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 13 10:02:00 2021 Return-path: Envelope-to: ged-emacs-devel@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 1maZD5-0006eA-1S for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Oct 2021 10:01:59 +0200 Original-Received: from localhost ([::1]:40934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maZD3-0006Cd-Fd for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Oct 2021 04:01:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maZBK-0005B3-2o for emacs-devel@gnu.org; Wed, 13 Oct 2021 04:00:10 -0400 Original-Received: from relay12.mail.gandi.net ([217.70.178.232]:54603) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maZBH-0002zh-Rh for emacs-devel@gnu.org; Wed, 13 Oct 2021 04:00:09 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id D408C20000F; Wed, 13 Oct 2021 08:00:01 +0000 (UTC) In-Reply-To: <87y26y7yxz.fsf@posteo.net> (Thierry Volpiatto's message of "Tue, 12 Oct 2021 20:44:23 +0000") Received-SPF: pass client-ip=217.70.178.232; envelope-from=juri@linkov.net; helo=relay12.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:276862 Archived-At: >> What does the following return? >> >> (let ((bar "bar")) >> (helm-aand bar >> (replace-regexp-in-string "b" "f" it) >> (replace-regexp-in-string "f" "o" it))) >> >> If it returns "oar" then it applies replacements sequentially, >> and we have no problem with such implementations. > > Yes, it does, thought you wanted something easy to read (and write), it > was the initial question isn't it? General-purpose threading like you proposed is a nice feature. But is supports only sequential replacements. >> But we need an alternative version that performs simultaneous >> replacements and returns "far". > > So I don't understand what you want to achieve. Most of replacements are intended to be simultaneous. But in practice most of simultaneous replacements could be performed using sequential replacement because often the result of every replacement step doesn't contain matches for the next replacement step. But sometimes simultaneous replacement is required. For example, (let ((bar "<&")) (helm-aand bar (replace-regexp-in-string "<" "<" it) (replace-regexp-in-string "&" "&" it))) will do the wrong thing (and will return "&lt;&" instead of the intended "<&") because these replacements should be performed simultaneously.