emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding support for xref jumping to headers/interfaces


From: Dmitry Gutov
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Mon, 27 Nov 2023 19:05:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 27/11/2023 18:41, João Távora wrote:
On Mon, Nov 27, 2023 at 4:23 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

On 27/11/2023 18:04, João Távora wrote:
On Mon, Nov 27, 2023 at 3:45 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

That didn't answer the above question. To signal "what kind of
cross-references it can find", it would define
xref-backend-definition-kinds with corresponding return value.

The answer was in the first two words.  "Of course", and the reason
is in the words following that.

So to be clear, yes, c++-ts-mode, if it ever gets such capabilities
should define c++-ts-find-declaration, c++-ts-find-partial-specializations
and so forth, but probably no c++-ts-find-implementation (fuzzy concept
in C++).  It should (or rather, it may) bind them in a given xref-provided
prefix map and they should become active when c++-ts-mode is active.

For "references" and "definitions" the existing xref commands will do,
but the phrases "references" and "definitions" should well be in the
"prompt for kind" list as options.

We in the end we'll have dozens of similarly-named commands with the
same implementation, right? Some of them in the core, others in
third-party addons.

What same implementation?? They only common part is is literally just
the string "xref-define-finder", the opening and the closing parenthesis.
Then comes the backend specifics.  A JSONRPC-based transport with a specific
protocol, an HTTP transport with another protocol, a ask the oracle of Delphos
protocol, etc.

Realistically, most people will be using Eglot anyway, so the existing
eglot-find-* commands are what they're going to see and use.

So that's what your argument comes down to in practical sense -- keep the commands in Eglot, and not worry much about other Xref backends. Whether they are alternative LSP clients or not.

Setting aside the issue of us binding ourselves to Eglot too closely, that *would* mean keeping those commands unbound for the foreseeable future. And I do remember users asking about the default bindings.

But you could put the existing xref-find-definition and xref-find-references
commands in it.  Even the "find-all" could be there.

That... doesn't sound very convincing, TBH.

That's obvious.  It's clear to me that you are already convinced
of whatever you want and all this discussion leads nowhere.

I'm saying it doesn't look good as an argument that I could make to convince the current head maintainers of Emacs to free up the "M-'" binding. Or any other short key sequence, probably.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]