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#58158: 29.0.50; [overlay] Interval tree iteration considered harmful Date: Tue, 11 Oct 2022 05:12:11 +0300 Message-ID: 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> 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="20727"; 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: gerd.moellmann@gmail.com, 58158@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 11 04:13:17 2022 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 1oi4lg-0005DN-St for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Oct 2022 04:13:16 +0200 Original-Received: from localhost ([::1]:41266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oi4lf-0003JS-2l for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Oct 2022 22:13:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi4lT-0003JJ-Vv for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 22:13:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51320) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oi4lT-00006J-NX for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 22:13:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oi4lS-0003nh-Hu for bug-gnu-emacs@gnu.org; Mon, 10 Oct 2022 22:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Oct 2022 02:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58158 X-GNU-PR-Package: emacs Original-Received: via spool by 58158-submit@debbugs.gnu.org id=B58158.166545434114562 (code B ref 58158); Tue, 11 Oct 2022 02:13:02 +0000 Original-Received: (at 58158) by debbugs.gnu.org; 11 Oct 2022 02:12:21 +0000 Original-Received: from localhost ([127.0.0.1]:50398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oi4kn-0003mn-7K for submit@debbugs.gnu.org; Mon, 10 Oct 2022 22:12:21 -0400 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:39734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oi4kl-0003ma-0t for 58158@debbugs.gnu.org; Mon, 10 Oct 2022 22:12:19 -0400 Original-Received: by mail-wm1-f45.google.com with SMTP id 8-20020a1c0208000000b003c6c154d528so188635wmc.4 for <58158@debbugs.gnu.org>; Mon, 10 Oct 2022 19:12:18 -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=lBtpSQKNbBuCsG48CYjIJOXtisQ2QMK5oeI+qf4glYk=; b=I6YcONTNHPJ0rO6Zxvq1Z5CsvEpPPf0NUZlrIKZllvP+py7OxubiHT/XTvpQ9VcJaD N0+zKGt+N8uRTx2QkaxRtpaJ2zOEUuXNgyF84P6RhRkFOYqZOZllDMI+Khw0hyKnv7KV EoraaUmk2JAHlXCJRtTdyCHu6/L/7rtMrdiBq/3sFzfu3bFbBBhfSTYSp+NSkeegCa0e pvNc06IUoz5ITrEe/LraCpqo8S+4JaQE13vBW1ws++qZy4zBW0o1IB037sFkt0xkEwTa o46qWwV5wmEcgM2AGH+clVQTVHkpkEQhJcaq2RSmkET5uNVgCXWvxDeD1pGRyhVUBqu3 gwVQ== 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=lBtpSQKNbBuCsG48CYjIJOXtisQ2QMK5oeI+qf4glYk=; b=IWbrRI1MOwHqN/HuPnF+8vauU+2Fbs6RJHUD5upyEF4Exgv8o73PxhTesk2aoJ7Bgi iwEYvXmUxWbzidZ5PcVZqk8cT7Fjb4bO0hdywfvmZ4oQPjDzwc0lgI3MwtudEJZOyhMP Ivg557cm0ztSb5fGYhVDfrMnGevWQKOT+LYgEs5a3v1FXoAtP7qZyk88lvSCfiPRxNYd r2GZntGcICRwzSPKhAfPZ1eGPvePo0zepat0zzl8SbxakqFt+YmoCd4tjDJsEqq/EXXM /HMJxMQOAKSrAA4A0ubxPfuOkV0SipbkjKAyHZy5Tt6YfZsIU7s669fLFgJapn85QA4D V4RQ== X-Gm-Message-State: ACrzQf0MshkXhDZ+e0q4QK5x8i/iK04UV2uQqxVB88rCvGRIag5oZwCf R99G/eAStIxvXXvqrgqvhjY= X-Google-Smtp-Source: AMsMyM6anPDUq1efeT/b42TC374ofjGMxMAz8Kb+fKFrXBIkNNh4oSmNSupeAqiL/jBOxJAyMFeWsg== X-Received: by 2002:a05:600c:5112:b0:3c0:eabe:80df with SMTP id o18-20020a05600c511200b003c0eabe80dfmr18355177wms.65.1665454332912; Mon, 10 Oct 2022 19:12:12 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id ck15-20020a5d5e8f000000b0022afe4fb459sm10366880wrb.51.2022.10.10.19.12.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 19:12:12 -0700 (PDT) Content-Language: en-US In-Reply-To: <838rlohzeo.fsf@gnu.org> 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:245076 Archived-At: On 10.10.2022 11:10, Eli Zaretskii wrote: >> Date: Sat, 8 Oct 2022 21:50:39 +0300 >> Cc:gerd.moellmann@gmail.com,58158@debbugs.gnu.org,monnier@iro.umontreal.ca >> From: Dmitry Gutov >> >>> Btw, what am I doing wrong below? >>> >>> emacs -Q >>> C-x C-f src/character.h RET >>> M-x visit-tags-table RET RET >>> M-. char_string RET >>> r whatever RET >>> >>> Unexpected result: "No suitable matches here". Huh? what did I miss? >> We can't replace over "find definition" matches: they are more abstract >> and don't contain the necessary information to perform the replacement >> (such as the length of a match, for instance). >> >> And such xrefs might navigate you to the beginning of the line, for >> example, rather than to the beginning of the name. >> >> But that makes sense, doesn't it? If replacing over "find definitions" >> results worked fine, in the end you would get a codebase where all >> declarations of a method 'foo' got renamed, but all callsites of it >> remain unchanged. That couldn't have been your intention, could it? >> >> The error message could use some improvement, I suppose, but I'm not >> sure how to make it better. > I tried to improve the situation, both in the error message, the doc > string, and the manual. It's probably better now, but still likely confusing. What is a "subset of matches"? The user makes a search, gets a bunch of matches. Is it fair to call them "only a subset" is the user only searched for definitions? Or to take another example, the user can search for some regexp inside a particular directly, with dired-do-find-regexp. Imagine that that directory is not the whole project (perhaps just a minor subdirectory). Would it be fair to call the results "only a subset" then? But xref-query-replace-in-results will work in that case, because the search returns values which have enough info to perform the replacements. Perhaps we should make the error very specific, like "you can't replace inside xref-find-definitions results". Since that is going to be the exception in like 99.9% of the cases. It's possible for other backend commands (such as find-references) to return unsuitable xref values in third-party backends, or for other code to use xref-show-xrefs with such, but those will be really very rare, if happen at all.