xref-query-replace-in-results error message after xref-find-definitions, was: Re: bug#58158: 29.0.50; [overlay] Interval tree iteration considered harmful

[Dmitry Gutov]

Moving from Debbugs here.

On 11.10.2022 09:37, Eli Zaretskii wrote:
> > Date: Tue, 11 Oct 2022 05:12:11 +0300
> > Cc: gerd.moellmann@gmail.com, 58158@debbugs.gnu.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > What is a "subset of matches"?
>
> Feel free to suggest a less vague description.  The idea is that the
> list in Xref buffer doesn't show all the references to the identifier,
> making renaming infeasible.

How about:

  Cannot perform replacements in this search's results

> > 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.
>
> That'd be my preference, but what are those 0.1% of cases where the
> Xref buffer produced by other commands could fit?

I suppose they will be covered by the above message, while in the manual 
you can explain it in more simple terms, since you don't need to worry 
about third-party code as much.

> More generally, what exactly does xref.el test to produce the error
> message, and how to describe that in user-level terms?

It tests whether the method xref-match-length returns non-nil for any 
search results. When they do, it would identify them as "match xrefs" 
(mentioned in the Commentary).

But I suppose that clashes with the terminology you prefer to use.

> > 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.
>
> You are saying that 'r' is only useful after M-?, is that right?  The
> manual says so, but the manual doesn't have to say "the whole truth".
> The doc string should.

It works after dired-do-find-regexp and project-find-regexp as well.