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

[Dmitry Gutov]

On 11.10.2022 14:51, Eli Zaretskii wrote:
> > Date: Tue, 11 Oct 2022 14:36:11 +0300
> > Cc: emacs-devel <emacs-devel@gnu.org>
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > 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
>
> 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? E.g. because the abstract we use for this operations (to 
support different backends) doesn't give us enough information to 
perform that replacement.

And also because replacing in xref-find-definitions results doesn't make 
sense to begin with.

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

> The commentary just
> says the "correspond to search result", which is not very useful for
> this purpose.

Search result as in result of a "full scan" of the directory. As opposed 
to looking in some small index which contains the definitions. At least 
what's what I was thinking of, probably.

But the find-references search could also be sped up with an index, so 
this is probably not worth differentiating in these terms.

> > > 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.
>
> So wed cannot say something like "This can only be used after M-?",
> sigh...
>
> 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.

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.

I tried to make a poll for that idea, but there were no conclusive 
choice on what alternative xref-show-definitions-function to use.