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: xref-query-replace-in-results error message after xref-find-definitions, was: Re: bug#58158: 29.0.50; [overlay] Interval tree iteration considered harmful Date: Tue, 11 Oct 2022 15:10:47 +0300 Message-ID: <5bb803bf-f51b-c175-f908-c60066d6967d@yandex.ru> References: <83h70qhez0.fsf@gnu.org> <83edvuhaby.fsf@gnu.org> <831qruh67o.fsf@gnu.org> <83y1u2foli.fsf@gnu.org> <83zgehe6iq.fsf@gnu.org> <95113379-99d8-eba4-f980-a7fca11430d5@yandex.ru> <834jwfmn5a.fsf@gnu.org> <838rlohzeo.fsf@gnu.org> <83mta2g91p.fsf@gnu.org> <237a3e26-03b8-a2a9-90bd-d50c3670a131@yandex.ru> <83wn96efyn.fsf@gnu.org> 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="40613"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 15:42:48 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 1oiFWx-000AOS-Bk for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 15:42:47 +0200 Original-Received: from localhost ([::1]:56132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiFWw-0002IT-0T for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:42:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiE6V-0001tm-P1 for emacs-devel@gnu.org; Tue, 11 Oct 2022 08:11:23 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:45876) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oiE6H-0004i3-J4; Tue, 11 Oct 2022 08:11:22 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id a10so21240058wrm.12; Tue, 11 Oct 2022 05:10:52 -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:subject:date:message-id:reply-to; bh=94T8T3It4bn3oYptSPjc5FPlzZMw0X5toJPE/X0QvJw=; b=iva/kngW5GHozAb87TXvFJH11YUrxm0YsLnslpyIehpLHVUqJumRQDAabZNHMONxDa haWP4rYrXFOVB88982f6nWmQxX2LW9CnAy/Ms7ISOFMDwmjNXzzkUoYQRBw8+nwLX62+ T0Lhrx2bnGwiql59siYT3Fm6ul8goLp9UVABCl3bNM8yxdjwGofunQ1LuWvTXLHEgyhs Ljj4oZ2EAJHS30OpueLP5j5+9NEFRvUp0yG8rx6j/m8wnn53TnlPWw7dLVLGrAjMm5bZ vpaOIFqdvzMiZ02+vlfGF233Psbn4fN0GanEgcQguTe7HICyC0RILT+eaYdUpGNRPtpB PZsw== 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:subject:date:message-id :reply-to; bh=94T8T3It4bn3oYptSPjc5FPlzZMw0X5toJPE/X0QvJw=; b=ftZyb0COc7ozRrs7r/8GCuhob47eG08RWdzFXEPYTQfzb/srOpnAdlyqPnMIGfv0DN 3A32nEu+88G+T0dLfrHKNTt0ZCMdYJGWZIgl3apA4KbYPc+jmL8Gx1yeZjN7yGTFM0Os s2RAWSLZSwXbZWl6e8cYqOUcyF2gr0VHFtoTD0sErKsYaHe+UgQM5Be5awrF+X4HpdNQ Iz+gTnKAKqTwhYg7uyWq+FkuYkrZZwRR6pkN31OSvbmS2pj3nLbjHPzomh2URo1fN3/n hB0zxhBHiha7UB652feD+WXRuRpK1KASY8r8gDx71b1BRiPd1J6Ic87cuEtHQhBsz8U7 av6g== X-Gm-Message-State: ACrzQf2QxdT8VOUMH/5DOl6/TCBb++1F7Y6ZxHNoIWpojokmg6qOdJoz QWHuDFiOHSVo338+2dh1y1PupFE6B7M= X-Google-Smtp-Source: AMsMyM6LhBQxDtwRAnhR09hbyPnmWDiBHHOqBq2TcyAoTVKR6uxxWBpig+yGfv6aE/fCFBalYwst4w== X-Received: by 2002:a5d:456b:0:b0:230:9e5b:c64c with SMTP id a11-20020a5d456b000000b002309e5bc64cmr6194557wrc.211.1665490249337; Tue, 11 Oct 2022 05:10:49 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i129-20020a1c3b87000000b003b50428cf66sm9415359wma.33.2022.10.11.05.10.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Oct 2022 05:10:49 -0700 (PDT) Content-Language: en-US In-Reply-To: <83wn96efyn.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42a.google.com X-Spam_score_int: -33 X-Spam_score: -3.4 X-Spam_bar: --- X-Spam_report: (-3.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.934, 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.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:297481 Archived-At: On 11.10.2022 14:51, Eli Zaretskii wrote: >> Date: Tue, 11 Oct 2022 14:36:11 +0300 >> Cc: emacs-devel >> From: Dmitry Gutov >> >> Moving from Debbugs here. >> >> On 11.10.2022 09:37, Eli Zaretskii wrote: >>>> Date: Tue, 11 Oct 2022 05:12:11 +0300 >>>> Cc: gerd.moellmann@gmail.com, 58158@debbugs.gnu.org, monnier@iro.umontreal.ca >>>> From: Dmitry Gutov >>>> >>>> What is a "subset of matches"? >>> >>> Feel free to suggest a less vague description. The idea is that the >>> list in Xref buffer doesn't show all the references to the identifier, >>> making renaming infeasible. >> >> How about: >> >> Cannot perform replacements in this search's results > > This is similar to the original message. It is, because it tries to be accurate foremost, covering all potential situations. But, like I explained, your new message is not much better: it still tries to be "high-level", rather than stating particulars, and while doing that, contradicts some objective facts. It might be worth it if it were very clear to the user and true in 99% of the situations, but that doesn't looks like the case. > Its problem is that it > states the fact, but doesn't attempt to explain it, and thus doesn't > give a clue what the user did wrong and how to fix that. How does one explain that we cannot replace in xref-find-definitions results? E.g. because the abstract we use for this operations (to support different backends) doesn't give us enough information to perform that replacement. And also because replacing in xref-find-definitions results doesn't make sense to begin with. >>> More generally, what exactly does xref.el test to produce the error >>> message, and how to describe that in user-level terms? >> >> It tests whether the method xref-match-length returns non-nil for any >> search results. When they do, it would identify them as "match xrefs" >> (mentioned in the Commentary). >> >> But I suppose that clashes with the terminology you prefer to use. > > If it's possible to come up with the semantics of xref-match-length or > of "match xrefs", maybe that could be useful. Those are basically generalized versions of xref file matches (also almost same info as what M-x Grep provides), which contain the line number and column, and length of the match. We obtain the first two pieces of info lazily, but we need the last one as well. > The commentary just > says the "correspond to search result", which is not very useful for > this purpose. Search result as in result of a "full scan" of the directory. As opposed to looking in some small index which contains the definitions. At least what's what I was thinking of, probably. But the find-references search could also be sped up with an index, so this is probably not worth differentiating in these terms. >>> You are saying that 'r' is only useful after M-?, is that right? The >>> manual says so, but the manual doesn't have to say "the whole truth". >>> The doc string should. >> >> It works after dired-do-find-regexp and project-find-regexp as well. > > So wed cannot say something like "This can only be used after M-?", > sigh... > > I still have no idea how to improve the error message. Perhaps I should remind that xref-find-definitions is still the main exception -- where this command doesn't work. We also had some talks previously where it's been suggested that we should try to show different UIs by default, for xref-find-definitions results, and for other xref searches. IIRC you disagreed. I tried to make a poll for that idea, but there were no conclusive choice on what alternative xref-show-definitions-function to use.