GNU bug report logs -
#58158
29.0.50; [overlay] Interval tree iteration considered harmful
Previous Next
Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Date: Thu, 29 Sep 2022 05:30:02 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 30.1
Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #134 received at 58158 <at> debbugs.gnu.org (full text, mbox):
On 10.10.2022 11:10, Eli Zaretskii wrote:
>> Date: Sat, 8 Oct 2022 21:50:39 +0300
>> Cc:gerd.moellmann <at> gmail.com,58158 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>>> 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.
This bug report was last modified 1 year and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.