From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Thu, 9 Nov 2023 01:06:37 +0000 Message-ID: References: <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <83h6uv47e8.fsf@gnu.org> <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> <835ybb3txt.fsf@gnu.org> <83wn3q311i.fsf@gnu.org> <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> <83o7p20wdi.fsf@gnu.org> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.fsf@gnu.org> <95afa441-18ae-e62a-be16-be73a545bbba@yandex.ru> <54cb435f-4d51-4c0d-43d8-2991dd7ee6bd@gutov.dev> <2a059680-825e-1ee0-5e7a-1127c3faab4d@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40632"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 02:07:57 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r0tWX-000AOV-Cv for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 02:07:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0tVW-0002f2-KC; Wed, 08 Nov 2023 20:06:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0tVV-0002ce-B9 for emacs-devel@gnu.org; Wed, 08 Nov 2023 20:06:53 -0500 Original-Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0tVT-0001RF-Fw for emacs-devel@gnu.org; Wed, 08 Nov 2023 20:06:53 -0500 Original-Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-507b96095abso347463e87.3 for ; Wed, 08 Nov 2023 17:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699492009; x=1700096809; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PXlytQepxiASerdvoTy9RmZ3TAYCkeyeoFnlRNMdHzM=; b=cExJsgXYpFK6Pc4GI9fg3DalUtqlmiZuGwC+JZMXQi/cM6pwBC3ndSode3bQCFtdNq i9smMweyqbQ+kZViaS7Cw1rPbzKnp1ME44qhfK9bDpqBl3aLNjLjP1VOkntuL168Zef3 8NP5Q0XMX1ZGqapWBWr9i2GvsSpqqKyrTVuGZjITvL9WQ/p5HYleYBLILxKHpUulCFdX aRZkv7N7BvqtkDqRtZPe0NoPZQHKSED5Ge4TawI/XXoBKI+vHLlSMYleygPUfmPVng57 qp95tFiqKOR6boDRyUyjUCzRu82BpsenkadCCpUBqMEWyeWHgYC1dqkk4vJ0n/6ll8Xv ps/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699492009; x=1700096809; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PXlytQepxiASerdvoTy9RmZ3TAYCkeyeoFnlRNMdHzM=; b=ICHecA5M1MKquiHXvXeQ2FcfrH9B7O32RIltsVu19RsO2UHfccuhv6rNdFr5bZv1BT 4bpPusI8wj898VMopiaN0p18bna9QmRwGAzkZKFR9Rtw/3CCiB0xHvIlVAz7+OzFSkIY it3MkJctrLggLMoZ6DAyHmBRhox9reOhM7Fh2Z3qFs0A8QQMZ+jd3I4F1HuspYMHY6zY SRkbkJIdD7zNEvdM3o2aorbnveh0vHoo6OL458OtGMgA6+8uRsb0HU0WUCEy4ILxxhSt E9rrUb4lO3ULrs5fe5qvtvpPmJsuXSlRs7h0O9DTseVqFlK2ldnzeQlcv6pwg/Qqn4kY nLrg== X-Gm-Message-State: AOJu0YxLq7O9/NjQKa2bPp6Py+eWbCX6SVWEbDBCEVJrPOzT3eFjT33p tmYfKiVTYLQbQMyCEwmx94tJslYemcmpNDQXm+Q= X-Google-Smtp-Source: AGHT+IHwluNb76ykfiVHB/Vl/TuYsIVnzkhgNrXhiQ60QKGZzGWY1895fNBiA+c1tUF5+DgiVBgpUOl64rM2oWuNa+g= X-Received: by 2002:a05:6512:502:b0:509:3835:73bc with SMTP id o2-20020a056512050200b00509383573bcmr158268lfb.55.1699492009506; Wed, 08 Nov 2023 17:06:49 -0800 (PST) In-Reply-To: <2a059680-825e-1ee0-5e7a-1127c3faab4d@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312374 Archived-At: On Thu, Nov 9, 2023 at 12:27=E2=80=AFAM Dmitry Gutov wro= te: > > On 09/11/2023 02:08, Dmitry Gutov wrote: > > Do you know which category does "eglot-find-typeDefinition" falls into, > > and why? Aside from the fact that it, historically, uses a separate > > endpoint. > > Hm, according to > https://github.com/rust-lang/rust-analyzer/issues/2541#issuecomment-56516= 6660, > "find-typeDefinition" goes to the definition of the type of the current > variable (at point). That's rust-analyzer interpretation. In practice, servers can do what they want. This is the LSP description The go to type definition request is sent from the client to the server to resolve the type definition location of a symbol at a given text document position. For example, an Elisp language server could use that to go to the place where the `typeDefinition` of a given symbol is set on that symbol. > That probably means it doesn't really fit with the rest of the commands > we're discussing, e.g. because the identifier it works on is actually a > type name Not in rust-analyzer, at least judging by what you described. Seems like the identifier it works on is a variable name, which rust-analyzer then associates with the type (being a strongly typed language it knows that) and then you get to the place where that type is defined. Super-reasonable, for rust. > (so the completion should be across types? ideally, at least, > if LSP supported that). Anyway, it shouldn't be mixed into "find > definition", at least if we go by rust-analyzer's meaning of it. Actually, no. Precisely in rust-analyzer's case it could be mixed. I see somewhere a reference to a variable, I do that command you're thinkin= g of and get the definition of the variable and the definition of the type of= the variable, both useful things. But you're right that it won't make sense for every possible conceivable language or server. But just don't worry. Leave that concern to server developers and LSP users. You're not going to magically fix LSP with the xref.el feature. The Emacs-LSP marriage is never quite perfect, but it gets a lot of love. Exactly like any good marriage should :-) Jo=C3=A3o