From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Looking at function Date: Tue, 12 Jul 2022 03:19:42 +0300 Message-ID: <3c642f4d-471b-d6d2-8519-b4707e1193ba@yandex.ru> References: <86edz8k6q1.fsf@mail.linkov.net> <86y1wzv4uv.fsf@mail.linkov.net> 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="33549"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 12 02:20:49 2022 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 1oB3dw-0008Zl-68 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Jul 2022 02:20:48 +0200 Original-Received: from localhost ([::1]:36082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oB3dv-0007BR-4k for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jul 2022 20:20:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oB3d7-0006V3-Dm for emacs-devel@gnu.org; Mon, 11 Jul 2022 20:19:57 -0400 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]:35746) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oB3d5-0003bx-GL for emacs-devel@gnu.org; Mon, 11 Jul 2022 20:19:57 -0400 Original-Received: by mail-ej1-x62f.google.com with SMTP id j22so11572596ejs.2 for ; Mon, 11 Jul 2022 17:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=h1p7lA+c59so+Ua/HH02sxY0mmeLMjVQ/2toYVXr9UI=; b=bbeWD1V250/oZtoUDhkXfmD2lV7Ge3d3kZQC3/NLXiu8xFTuwu7ybGHZp0KEQMEv01 /8uw4tbud/0iiPO7QpxUG20gkb6oj5MREWVQQ8eOUoife5DSoe55jsTwtURI54sHS9EK LoqdYXFDHd9ngVwhjWUmdFvatcsxCdXL5qBH5wRvuaGfYwOCLfVjIw/WE4QSDRi1mUev vY/yKIxfpE5zS+DXPCQYSMwv6u2tbA0HI0kcJG3yxuYXvdb5LlkbAf4Z8KTNCGu+98Hu NdN/VHtWZCnuPbRrTtaLWKag1nXrwhetHFbJDqTUy+zBTrG4xnVuJnVRY8RyMHHydep+ RS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=h1p7lA+c59so+Ua/HH02sxY0mmeLMjVQ/2toYVXr9UI=; b=EMZml4/r7BRqXXijxr/6S+GtL57uvZi/j95D82RiOf5tNCHf5lB3C2UIrzJwwOnPxd wIYy0UjE9V1MA8Kxn3tBaXrYv4ufvOhhgXJ45FtdDUSlH30LeFwD5d9kpphETA514ARS 5oLCTUlwWKKzKKlANtQtv3uTPyCvXxdS18xNJsIZ+XYti68ys5Y0/Yy/+HB5xNvCKbSp 4Zfo6hMQPoDB/ZV6zlOSbRwwM+72ZEXrzGmgu81zxXVA6OLpQmsIAsVhhbf4VJPXe5Dc Zl57VCDo9JEbhw59bxO0ZASuNespg5QdvY6z3/8x2mAbL4BMxniCMKQSvKh2Bhza32ri 7oLQ== X-Gm-Message-State: AJIora+VQ43VPIZ6cFRq5+3pDi+cIVowAlRcZdKjHONxadppNKL/5a7/ XQTh2vq9npZT7fonL20uyxo= X-Google-Smtp-Source: AGRyM1tdsWy+J4hgf/HFm2XaFe4NURlK4lJVPujqlD/oZ2xTsKPFeFI4PP7TFJi5Id1ssMEHgdAh0A== X-Received: by 2002:a17:906:4482:b0:70a:19e3:d18a with SMTP id y2-20020a170906448200b0070a19e3d18amr21401861ejo.510.1657585184392; Mon, 11 Jul 2022 17:19:44 -0700 (PDT) Original-Received: from [192.168.236.48] ([173.237.64.48]) by smtp.googlemail.com with ESMTPSA id z9-20020a170906270900b00722e50dab2csm3183950ejc.109.2022.07.11.17.19.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jul 2022 17:19:44 -0700 (PDT) Content-Language: en-US In-Reply-To: <86y1wzv4uv.fsf@mail.linkov.net> Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=raaahh@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:292063 Archived-At: On 11.07.2022 22:14, Juri Linkov wrote: >>> 1. Replace ‘looking-at’ with a call to the search function, >>> but keep it at point by prepending ‘\\=’ to the regexp. >>> Can it break a complex regexp? >> >> I suppose it can. Even a simple one (that has \\| inside without >> a grouping). > > This is what the fix for xref successfully uses in bug#53758 > with changes in perform-replace from bug#14013. (However, > none of these variants is suitable for replacing another call > of looking-at in isearch-search-and-update.) Right. Because xref basically uses literal matching, no alternations. But it will break more complex cases. >> Do we have a clear understanding of the idea behind this looking-at call? >> >> The comment says: >> >> ;; Otherwise, if matching a regular expression, do the next >> ;; match now, since the replacement for this match may >> ;; affect whether the next match is adjacent to this one. >> ;; If that match is empty, don't use it. >> >> What happens if there are multiple adjacent matches in a row, not just 2? >> I suppose the replacement could be performed for the first one, then the >> next one is "popped" becoming the current and looking-at is called again >> near its end? >> >> If so, perhaps a good alternative is to stop caring about whether those >> matches are adjacent and always store the latest two matches, whether they >> are next to each other or not. > > The sole purpose of this "do the next match now" hack > is to handle a special use case that is tested > in test/lisp/replace-tests.el: > > ;; Test case from commit 5632eb272c7 > ("a a a " "C-M-% \\ba SPC RET c RET !" "ccc") ; not "ca c" > > ;; Test case from commit 5632eb272c7 > ("a a a " "\\ba " "c" nil t nil nil nil nil nil nil nil "ccc") ; not "ca c" All right. So it seems the idea of keeping references to the two latest can work. No idea how big the changes will have to be, though.