bug#58158: 29.0.50; [overlay] Interval tree iteration considered harmful

[Dmitry Gutov]

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<dgutov@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.