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: Mon, 11 Jul 2022 04:26:15 +0300 Message-ID: References: <86edz8k6q1.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="20208"; 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 To: Juri Linkov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 11 03:27:25 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 1oAiCr-00057D-OB for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jul 2022 03:27:25 +0200 Original-Received: from localhost ([::1]:57120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAiCq-0006Lp-BJ for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Jul 2022 21:27:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAiBy-0005dW-35 for emacs-devel@gnu.org; Sun, 10 Jul 2022 21:26:30 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:51182) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAiBw-0002No-0P for emacs-devel@gnu.org; Sun, 10 Jul 2022 21:26:29 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id p4so2248475wms.0 for ; Sun, 10 Jul 2022 18:26:18 -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:references:from:in-reply-to :content-transfer-encoding; bh=zgxFos0g8b/LaviMZbIJUYYplwLXiBM1TLiibgIDofE=; b=jImtgf51ztheVHHN7K9SNdhDVwGmQdGVrmHeU3EY3zVx37hOT6og978wyyOigKCyqB Ay++NmsApBBS2WTZjl0t+NeST+pfG7qZNpawI2NnpfbkghYAAlMsie0Tl1oEiAPhsyKZ JMWPHlbUUwy2J+TtVUVcFhJtdDCoYaNqzzekhz/EfJP0N3bHb32xJPOZ7VvycUeiRm28 lDiK2bhhsCa/lHjFDTTCKJN9ggu2DPf1KGae5i/D6CcEJTfLwByuBz1kAnTCpF+uMUxw kDWRVk2mJZTmVnIysadovpfwpbI/Rp5HZ2aTkWq1JXQeNTbPRjS9i/JYCAO/dUqjOMW/ Le0w== 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:references:from:in-reply-to :content-transfer-encoding; bh=zgxFos0g8b/LaviMZbIJUYYplwLXiBM1TLiibgIDofE=; b=gHGr9UI+WW79M4h6yPNm9J5wcEUlrSkQmRFYrZ3oyMsaKdrR+bvlT9GD0EfBlye7SH aLK9O+1+ZePdLmM7P+8xQC2DRebGt78/gc3xivKISJs4ORX631uOXbtPbZMqG1v0+oap DK2fWXaLcWMHpPfbod9UpEE0BEt3pGZufigpNkDAjfEKCjpGEYz5jOrjgCr4qeZ6po/F 7ag9RuhsoQ049kMuanqPoxd2sC00i3eR/1rR/WD1sfvbPP32jcrY43FJFBBxMZEbl+Pc 7RVhqLPmRrmJms8j0JKvTmmXQM16gxqxzTYGLq3kp0zX5noPt+m9J2OTttRdrB7GKw8D 4YKw== X-Gm-Message-State: AJIora+MpXRSnPqqhhk3mcZfPneGuGXUF9iNRdX2ef/VWxvlk/B7vidU yyGkP/pFaVyoti8UnM8uF3M= X-Google-Smtp-Source: AGRyM1uDGJTKnI372OD/yGT0WoWKulT065LQSoXGXjsD5U180D+fzhSJQbiy/0X71MCU+/rUYwifdQ== X-Received: by 2002:a7b:c314:0:b0:3a0:5750:1b4a with SMTP id k20-20020a7bc314000000b003a057501b4amr12900006wmj.20.1657502777716; Sun, 10 Jul 2022 18:26:17 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id co1-20020a0560000a0100b0021cf31e1f7csm4535694wrb.102.2022.07.10.18.26.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Jul 2022 18:26:17 -0700 (PDT) Content-Language: en-US In-Reply-To: <86edz8k6q1.fsf@mail.linkov.net> Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=raaahh@gmail.com; helo=mail-wm1-x333.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:292041 Archived-At: Hi Juri, On 28.06.2022 21:01, Juri Linkov wrote: > Any use of the function ‘looking-at’ is incompatible with a non-default value > of ‘isearch-search-fun-function’. So there are following problematic uses > of ‘looking-at’: > > 1. There is 1 call in isearch.el in ‘isearch-search-and-update’: > > (looking-at (cond > ((functionp isearch-regexp-function) > (funcall isearch-regexp-function isearch-string t)) > (isearch-regexp-function (word-search-regexp isearch-string t)) > (isearch-regexp isearch-string) > (t (regexp-quote isearch-string)))) > > It doesn't call a non-default search function when using a key sequence like > ‘C-M-r ^’ on rectangular regions — it matches outside of regions > when the search function restricts the search within the region bounds. > > 2. In replace.el ‘looking-at/back’ are used only in ‘perform-replace’ > to check if the next match is adjacent. This causes problems during > rectangular replacements to find matches based on a non-default > search function. > > These possible solutions were proposed in bug#54733: > > 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). > 2. Call the search function as above but afterwards check if > (match-beginning 0) is equal to the original position. > Less efficient. I don't think efficiency would be a problem here, but tricky search functions could be. Like ones that expect to be called a specific number of times (replace-re-search-function inside xref--query-replace-1 is one such example). But if the code could be rearranged such that the search function is called the same number of times but does something different when it's found right away. Or of course we could mandate that the search functions are never written this way (it's pretty ad-hoc). > 3. Use looking-at only when the search function is default. Probably would fail some of the scenarios similar to which the looking-at hack was added for. > 4. Add a new variable ‘looking-at-function’. > It could be like ‘isearch-search-fun-function’, so redefining > the search function will also require redefining the > looking-at function with similar code that doesn't move point. I suppose this is a safe alternative. > Any better ideas how to replace looking-at with something > that uses a search function? 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.