|
From: | Dmitry Gutov |
Subject: | 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 |
Date: | Tue, 11 Oct 2022 15:44:18 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 |
On 11.10.2022 15:17, Eli Zaretskii wrote:
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?That's what the "subset of matches of identifier" part attempts to do.
A high-level and not very accurate description, because it's only relevant for the difference between xref-find-definitions vs xref-find-references, but not when the *-find-regexp commands come into play.
And also because replacing in xref-find-definitions results doesn't make sense to begin with.I agree that it makes no sense. The problem is how to say that in a general enough way.
"Not supported" is not too terrible an error message if we are sure the user is trying to do something they shouldn't even attempt to.
But we can try to be helpful by offering an alternative:Cannot replace in this search; to rename a symbol, invoke \\[xref-find-references] first
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.And why do the results of xref-find-definitions lack that?
So that the backend isn't forced to provide info that's harder to get, and that we don't use anyway. E.g. M-x find-function just brings you to BOL rather than to the beginning of the symbol.
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.But not the only one?
The only known one, so far. Although it might depend on the backend as well. The built-in backends are going to fail, but it seems like lsp-mode at least returns "match xrefs" for all searches. Maybe Eglot too, I haven't checked.
That would mean that one 'r' can work in lsp-mode's xref-find-definitions results (they define a bunch of custom commands like lsp-find-definition and lsp-find-declaration, but that probably doesn't matter). Not sure if we should do something about that.
[Prev in Thread] | Current Thread | [Next in Thread] |