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.bugs Subject: bug#31796: 27.1; dired-do-find-regexp-and-replace fails to find multiline regexps Date: Thu, 3 Dec 2020 04:46:43 +0200 Message-ID: <00d1c8ef-5601-6445-199e-1590ddfae9e9@yandex.ru> References: <10120030-8b8d-b702-add4-8f099f934ed5@chalmers.se> <831rgivl7l.fsf@gnu.org> <83lfequ30g.fsf@gnu.org> <83a6v6tss9.fsf@gnu.org> <08c0bbce-051e-7a49-106a-d6d0629b2224@yandex.ru> <87blffns95.fsf@mail.linkov.net> <8c124412-3bb3-fd92-4c3b-da4b3a8bdcac@yandex.ru> <87blfec4l3.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="18353"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: abela@chalmers.se, 31796@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 03 03:47:21 2020 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 1kkeeO-0004cv-25 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 03 Dec 2020 03:47:20 +0100 Original-Received: from localhost ([::1]:42808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkeeN-0007tW-1P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Dec 2020 21:47:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52200) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkee7-0007t9-Hv for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2020 21:47:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kkee6-0005x1-6w for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2020 21:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kkee6-0005nm-4M for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2020 21:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Dec 2020 02:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31796 X-GNU-PR-Package: emacs Original-Received: via spool by 31796-submit@debbugs.gnu.org id=B31796.160696361522289 (code B ref 31796); Thu, 03 Dec 2020 02:47:02 +0000 Original-Received: (at 31796) by debbugs.gnu.org; 3 Dec 2020 02:46:55 +0000 Original-Received: from localhost ([127.0.0.1]:37910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkedy-0005nR-Kk for submit@debbugs.gnu.org; Wed, 02 Dec 2020 21:46:54 -0500 Original-Received: from mail-ej1-f44.google.com ([209.85.218.44]:44553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kkedw-0005nB-Gl for 31796@debbugs.gnu.org; Wed, 02 Dec 2020 21:46:52 -0500 Original-Received: by mail-ej1-f44.google.com with SMTP id m19so1146408ejj.11 for <31796@debbugs.gnu.org>; Wed, 02 Dec 2020 18:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZbMHvETBfsELd0eyMngZ4vYFuboos2leNnzXF2O84i8=; b=oC71Oi+dXSBbM/UynksI2ssrjdY/FwniDbU7MjzzmkXda5rputNU9sfON6iHBYt6Wc QmYH58r0wwjDQK8JDmL1Bp2dDHyRQMUEjEkEJ2HrA2e7vNvge5TFmcKt7K6wjQrrtFWG jX8WzbbLvJol8QofDg20jzIdMMfUKEw5MM5FFe67dIH8b/ZBqFJKWf54nWSCREgDGgFE /OwM2By66dvSkB/VN047R7vD23skjzm5IQ3JbBvH6tdC7gDglKpQ71nSNZDQ7dz+Hzyy YIYpZT9jfzOr5qxYV2p2pOcEqHeLeLiTnXNciIHtBHcoDqcH95B8srJ6w4mAzzwNJ4Nr ymyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZbMHvETBfsELd0eyMngZ4vYFuboos2leNnzXF2O84i8=; b=g8ysfERC7xU84LM0SfbOivRG7kNrvcojpNRgaxvkxVnYHZ+t950FBZwkASVufvYOVq agnoiW4Uwd2n856i51smjoy1PiOMbHCQxAklIzsn4MjkWgBapegqoOeUZ5386g2YeO32 PT4dG0++J4bmcX2edSBG9OxIEC/aBiVxSGEL+3XkqEGbKN+qO3O4BswCkB9itorA/xCR MlPpqvRqgUXKZF/WV/ZT1CtUnkLmkEbJBuCbnXvtkjiGeCCQZZZfJ3bWac0v1b02Xa/C jO5T0ymth1+/e0K1Efhqj5hMAnz+ynSQh67o10Df2HzzgniBv2btGdbWNrfVNfoCUFdC wExg== X-Gm-Message-State: AOAM531r3AMbaK/5loaq9q+VR6wGcFeHH0Di5VwlPL3h5QvT7QG26jIp JEo5W2gTHMoS+JXCXtBtE7tbXJsj9JsYVw== X-Google-Smtp-Source: ABdhPJw7Nm9fYRfTF/oZjGzEqo5ymkQJVQY2TmzUDPcWcNdpyTrgohMB318WSeCvVEjybEgI5luEGw== X-Received: by 2002:a17:906:2e82:: with SMTP id o2mr751667eji.106.1606963606273; Wed, 02 Dec 2020 18:46:46 -0800 (PST) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id ch30sm148696edb.8.2020.12.02.18.46.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 18:46:45 -0800 (PST) In-Reply-To: <87blfec4l3.fsf@mail.linkov.net> Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:194844 Archived-At: On 01.12.2020 10:39, Juri Linkov wrote: >>> When a grep input pattern contains a newline, then xref could use >>> the same algorithm as is used for 'M-.', i.e. run 'grep -Pzl' >>> to get the file names that contain the pattern, then return >>> these file names without line numbers. >> >> Do you mean the xref items backed by find-func.el? There are a particular >> kind of references which are usually unique enough that special navigation >> logic can work. It's also implemented this way because the search can be >> performed without reading file contents (which would be slower). > > I meant xref-matches-in-files. 'M-.' doesn't use xref-matches-in-files. > It could also use another regexp > for the output of 'grep -Pzo' without line numbers. Not 100% sure I understand you here, but hopefully this line of discussion is continued below. >>> This works exactly >>> like a new feature of extending xref-show-xrefs-function >>> with a new completion function was proposed recently on emacs-devel >> >> For Grep results, I think the line number is important because we're even >> more likely to have multiple lines with the same contents in one file. > > Yes, sometimes this might cause inconvenience when the user wants to visit > the second occurrence of exactly the same line. Or 5th or 10th. Where this would be more important, though, is when the user will want to change all these lines at once with xref-query-replace-in-results. Also, it'd probably be surprising to see Grep search results without line numbers. >> What we *could* do, is run Grep, then take just the list of files names >> that it returns, visit them all in Emacs and repeat the search in all of >> them. But that would require a more complex abstraction than just "search >> command", as well as some juggling of buffers that weren't open before (we >> don't want to add more open buffers just because the user has run a search, >> right?). > > dired-do-find-regexp uses 'ignores' to filter out ignored files. > You could add another filter to filter out files without matches > using 'grep -PzL'. Right. This is sorta a backup plan. Although, when the number of files to search can be counted on one hand, there's nothing too bad in doing the search in Emacs. >>> (BTW, why it's not installed yet?) >> >> Waiting for the feedback. >> >> It went through several minor revisions. Do you like the most recent >> version? If so, please reply to the message containing it. If you don't, >> please also reply and say why. > > I suggest to create a new bug-number for it. If you think it's best. The original thread author decided to write to emacs-devel, maybe they're more comfortable there. *shrug* >>> So like this feature presenting such completions without line numbers: >>> lisp/progmodes/project.el:(cl-defgeneric project-root) >>> lisp/progmodes/project.el:(cl-defmethod project-root ((project (head transient)))) >>> lisp/progmodes/project.el:(cl-defmethod project-root ((project (head vc)))) >>> xref for grep could work the same way without line numbers: >>> lisp/progmodes/project.el:names"^Jproject--read-file-cpd-relative) >>> lisp/progmodes/project.el:names"^Jproject--read-file-absolute) >>> Then visiting such grep hit should use Emacs search functions >>> to find the grep hit in the visited file. >> >> These are two substrings inside that file that matched the search >> regexp. But there could be substrings in the same file that are equal to >> either of these but don't match said regexp, e.g. because they are preceded >> or followed by some different contents. > > How is this possible? Please show examples. Hmm, apparently no examples possible with Grep (which treats all lines as independent strings), but if we take ripgrep, or other regexp engines, they can use anchors like \A (counterpart to \` in Emacs), or PCRE's lookahead/lookbehind. As long as dired-do-find-regexp is documented to simply "use constructs supported by your local [search] command", the user could take advantage of some advances syntax like that. Though we might have to limit that capability if the idea of post-filtering search results using Emacs's own engine comes to life.