From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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:17:44 +0300 Message-ID: <83v8oqeeqf.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29930"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 11 15:25:06 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 1oiFFq-0007Vk-3D for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 15:25:06 +0200 Original-Received: from localhost ([::1]:37620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiFFp-0000n6-4h for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Oct 2022 09:25:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiECX-0008Ez-8t for emacs-devel@gnu.org; Tue, 11 Oct 2022 08:17:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35122) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiECW-00068e-W5; Tue, 11 Oct 2022 08:17:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SSLnO3l0mwdza3WTvJBJ4M3JRn0GtJI0WMt1934T8Q0=; b=f9o3ueWpUYSJ zHKzF+OxiLevXXi2JxN8fRBu/A/E+muSf8OxeEDeeW4EONd9t9sv/AgwghljArWpjRHXZz29MdBXM SGaYWDnCBwIlGtU0dr+Dz6jfivyhlueE0IO9Y5EopnrhozCpFu1xwDaqAz9+r7Ll8oSkyWfna2TC2 Lito69w6FWT5BJ2UBrGUYbGGXN2qxqOs6ThqenuTRH7kisf0TEYbtinOZruc3tk69VOWfBtl65SYR MO8B/yqYRofrOEhANj/3zp8FdtONENsXsNH5P3malisaznEYLoEmCAwleY+F82Kk+91bTjMERmEr2 kg0EBdizWCvovbfmGyEPHQ==; Original-Received: from [87.69.77.57] (port=2391 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiECW-0000TA-F4; Tue, 11 Oct 2022 08:17:36 -0400 In-Reply-To: <5bb803bf-f51b-c175-f908-c60066d6967d@yandex.ru> (message from Dmitry Gutov on Tue, 11 Oct 2022 15:10:47 +0300) 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:297477 Archived-At: > Date: Tue, 11 Oct 2022 15:10:47 +0300 > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > > >> 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? That's what the "subset of matches of identifier" part attempts to do. > 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. > > 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? > > 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? > 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. 'r' is just one command which is sensitive to the differences. AFAIR, most other commands aren't. So it makes sense to use the same UI.