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: Wed, 17 Aug 2022 03:27:48 +0300 Message-ID: <875d1684-e3d7-a16c-7fee-b5a03e45edce@yandex.ru> References: <86edz8k6q1.fsf@mail.linkov.net> <86y1wzv4uv.fsf@mail.linkov.net> <3c642f4d-471b-d6d2-8519-b4707e1193ba@yandex.ru> <864jzm4u9f.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11617"; 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 Wed Aug 17 02:28:59 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 1oO6va-0002sg-Je for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Aug 2022 02:28:58 +0200 Original-Received: from localhost ([::1]:58154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO6vZ-00035s-0y for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Aug 2022 20:28:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO6uf-0002QO-9x for emacs-devel@gnu.org; Tue, 16 Aug 2022 20:28:01 -0400 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:47075) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oO6ud-0002YO-KS for emacs-devel@gnu.org; Tue, 16 Aug 2022 20:28:01 -0400 Original-Received: by mail-wm1-x32b.google.com with SMTP id k6-20020a05600c1c8600b003a54ecc62f6so200506wms.5 for ; Tue, 16 Aug 2022 17:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=TXu7JBD9CopF6HDjg8B5Ku66i60jVG5jWiLXn5vcn3w=; b=eyXxq9N0JNNpRlQPOCKhyGOX2bBe2N4vyQArzGqcfL8SR7VM5Sdm3nMJwAYDNUqn0N kBBq0IEntsnoPDloARjxV4trL+4/UcTZ9IZHSNhc9w/es5BlmsbDKLgipBl4xvCsPNgk zYAFJGpWuvyA9FmgMk2o5jo3F2ah2mQN9hdiEsQ0UUtBsRZWcMb3Y1QO3K9p8rsUyiiV w7+PA0eeLiFxKPwBqrKy/mJVMJjgziaq8Ha43pO3/u2SizqqlIjaPEvUy8f3/J6TbOM2 uE5nU3tOnPTBbzP3c2kaPZZvXthulGw2ho0r7suFg5Ns6fje8ds6rtC/ahurwYQz2Uzh iRyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=TXu7JBD9CopF6HDjg8B5Ku66i60jVG5jWiLXn5vcn3w=; b=cCnznMIRyhGsfH4G31GF5Nnp+Q+Fwy2K7B2Vq8k0+/e4qvlNKjqB6pbHB+7/FjdOBR BZ45D8waX2O3GxlJ4C6ELj8GMW1u9VtJWxAqS3WqRyVPuwC0LV5yAkMCI11oCPQFaMlZ dpH51fVPv8572D/lScbB92sKWVCU2NFqZFAx8pc6Nk/yyzZjy8jWm1xYqMRyGLHycz+0 D7ni4Xd4tV0EJH18irQ7yMVGTJbugAsjN5i5dvBxBCJFt1sk+jcYky025M5Jj29p97VD mAPs17w5Rg9Wdu9UmeCm5L/WuEDZ5tgCvpPrJGGwtTDN4Uogf61hG8DiIqwVCr2sqhTD 4j9Q== X-Gm-Message-State: ACgBeo3lmP62lqDT8ykQzw8wS4R7wfB7MhWAF6CayH3Rx1uQlOAoxvwu XNjIxYkWUTZEzTJvyQfYM4o= X-Google-Smtp-Source: AA6agR6BOECc27BWmkJ7zKYiaJtRPCblnKklEtN5SNvITm2nUantZd+278KGwtlhHuAGOcaYxLsf8Q== X-Received: by 2002:a05:600c:2315:b0:3a5:c2cc:1bee with SMTP id 21-20020a05600c231500b003a5c2cc1beemr472745wmo.55.1660696069690; Tue, 16 Aug 2022 17:27:49 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j4-20020a05600c300400b003a601a1c2f7sm340652wmh.19.2022.08.16.17.27.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 17:27:49 -0700 (PDT) Content-Language: en-US In-Reply-To: <864jzm4u9f.fsf@mail.linkov.net> Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32b.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:293522 Archived-At: Hi Juri, Sorry for the abysmal rate of replies here. isearch is really hard to fit in my head. On 12.07.2022 10:50, Juri Linkov wrote: >>>> 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? > > Actually, this is how it worked until now. > >>>> 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. > > And this is how it's implemented by the patches in bug#14013 and bug#53758. Sounds good, then. So this is a workable solution? Or have you come across some pitfalls? >>> 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. > > Shouldn't keeping only one reference be sufficient? By "two references" I meant the current one and the next one. Seems like the necessary minimum.