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:44:18 +0300 Message-ID: <7c0849be-145e-e073-49b5-63749e8d8282@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> <5bb803bf-f51b-c175-f908-c60066d6967d@yandex.ru> <83v8oqeeqf.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="8930"; 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:28:45 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 1oiFJN-0002E0-K4 for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 15:28:45 +0200 Original-Received: from localhost ([::1]:59638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiFJM-0004XN-40 for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:28:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiEcj-00061R-0E for emacs-devel@gnu.org; Tue, 11 Oct 2022 08:44:41 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:44008) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oiEcg-0004QB-27; Tue, 11 Oct 2022 08:44:39 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id r3-20020a05600c35c300b003b4b5f6c6bdso8041640wmq.2; Tue, 11 Oct 2022 05:44:21 -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=9YBUXYig1TvX0Of93vlJQEM5OaX+Ge4WV1s2Fbh7itk=; b=j45XL+0GkANC3cCrT7NrgPcD6XMbHy2V1EaLLc1xuKUVe3im0whLLYMh0ky4x8guOX h7dhz2QRFe8/mWg9Nz0v7a/SpsC8XdsNs+fO9YXiN3qj0v+/50wqxvq6RgYGgHxAiaFJ DH+4zO4Qe7/DhtvytEDqSxc5cvj7NI1KpzGDWe+aDQ/Y45DHdbhvYLNjdX6+NAH0pocn OxsZbqhSjMVc4ub1DMOQDtclgFD2f87ZOGuGE4SBsxQ4AmjZhZepMBI4cnGUaGIYdYub n6F4N7drTkw3meRU07x98MJjkpObjM/kd8o4BwPuyAw6UpBr8TbRdswjJ4CCz3sLCXGa ZDNA== 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=9YBUXYig1TvX0Of93vlJQEM5OaX+Ge4WV1s2Fbh7itk=; b=7IV7GHzgWRsY7vdqbycagqY48ie/3hiXfRmlF4OsHtr+uxw2K66MpTfr5IAoBrfJDP UELCqZ+lrWDRAwzT0cIsEINfgLHAMHu5Dfd0A58krjy2w5EN5UXySrurJyotlVVO5u6X ptfj6zxBRBfth0sYNnQ869lttzDULo6k9ny2fNbn0pjXLPcd8V5uQ0Wi5dM2Xea0JttY VA9853EODfeWSbxNYLHqGzIeC5uo9Qg6cQiwp2FTcNg9MZiEghGc2adNZbMUT5nbMUJw BRS0QcGTFBfeLOOIUlg2u4KjtqgyjSdbZrTcHyVuSRUWkr3MXpRtXxcgQ6m23CgiLBS4 dsRw== X-Gm-Message-State: ACrzQf1BBAcQ6qMJFOeIKhumkWYv5whGgQrA04LW3CNVW1Ehq04Z1iox u+0B8ulSzoShEs0ngzNhScuTvnZiSXU= X-Google-Smtp-Source: AMsMyM7imnq4erY11sfBIYzpr5pxlzOi2ZEgO5kTpqB1sHmXMld82nHxWAp07mGvwDoY6NbH7Ft8Eg== X-Received: by 2002:a05:600c:2b88:b0:3b4:8680:165b with SMTP id j8-20020a05600c2b8800b003b48680165bmr24611567wmc.113.1665492259886; Tue, 11 Oct 2022 05:44:19 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f15-20020adffccf000000b0022c906ffedasm6654824wrs.70.2022.10.11.05.44.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Oct 2022 05:44:19 -0700 (PDT) Content-Language: en-US In-Reply-To: <83v8oqeeqf.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=raaahh@gmail.com; helo=mail-wm1-x330.google.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.934, RCVD_IN_DNSWL_NONE=-0.0001, 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:297478 Archived-At: On 11.10.2022 15:17, Eli Zaretskii wrote: >>> 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? > > That's what the "subset of matches of identifier" part attempts to do. A high-level and not very accurate description, because it's only relevant for the difference between xref-find-definitions vs xref-find-references, but not when the *-find-regexp commands come into play. >> And also because replacing in xref-find-definitions results doesn't make >> sense to begin with. > > I agree that it makes no sense. The problem is how to say that in a > general enough way. "Not supported" is not too terrible an error message if we are sure the user is trying to do something they shouldn't even attempt to. But we can try to be helpful by offering an alternative: Cannot replace in this search; to rename a symbol, invoke \\[xref-find-references] first >>> 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. > > And why do the results of xref-find-definitions lack that? So that the backend isn't forced to provide info that's harder to get, and that we don't use anyway. E.g. M-x find-function just brings you to BOL rather than to the beginning of the symbol. >>> 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. > > But not the only one? The only known one, so far. Although it might depend on the backend as well. The built-in backends are going to fail, but it seems like lsp-mode at least returns "match xrefs" for all searches. Maybe Eglot too, I haven't checked. That would mean that one 'r' can work in lsp-mode's xref-find-definitions results (they define a bunch of custom commands like lsp-find-definition and lsp-find-declaration, but that probably doesn't matter). Not sure if we should do something about that.