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: Mon, 27 Nov 2023 15:03:35 +0000 Message-ID: References: <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@gutov.dev> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> <87sf4scxax.fsf@betli.tmit.bme.hu> <9ac758b8-5fb2-9b3d-7947-96777694e3e0@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="32120"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Felician Nemeth , Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , Filipp Gunbin To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 27 16:04:21 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 1r7d9p-000874-Ez for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 16:04:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7d9X-00034s-0h; Mon, 27 Nov 2023 10:04:03 -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 1r7d9U-00032v-Jc for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:04:01 -0500 Original-Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7d9O-0006LQ-FP for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:04:00 -0500 Original-Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-50baa7cdf6dso2614528e87.0 for ; Mon, 27 Nov 2023 07:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701097427; x=1701702227; 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=9rM59scyqsRwmmcrWrCo6jITFJvA+YaHzsJU8cPf0oQ=; b=I+b7DJPzmma0jzvQD2Hqr8Ir6XLZGcxSz4FJ2MSDk78iY1w56RG9i80mMiyxP+RGVs FAO2yd8/qGDfvHXZ8dQqbcHQ6d5K8Bs4OYf3LaugC9h3LkKKYTP0ZJNCTPyEK/Dyj9Sk GJug9yM2zDR1iebY3ubNqmn5MKesx56tOQZtGhGsYu9MhjRu6PU6SmWkEmtswH7KSz8x m8jRYWQ+3Vh8MWssBg1TNmoEZfCnKP4iA/CFEmiEFNqZGeVIqkZozEqgctlwA281HSkD rtdHYBOzqVxr8MAsTEecaC+NG2CxZcMcR+j7Czcjt02W3Bah+mgC9UdpTK+z/kslpCs3 fIig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701097427; x=1701702227; 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=9rM59scyqsRwmmcrWrCo6jITFJvA+YaHzsJU8cPf0oQ=; b=vP+Cy35xwJ0TPciaotK7SshCVy6/rSi4x/he7sSecBiLkIsxcCnfAhjn7UxyEK4jXm 21FKfrReNItFLG4MEOiYUD8GPy7NXbFsbmQVmdKI8UMfGV2Lq0wbvgY3DSvSoOLiCoyV m+6On3Fkc4RuX+p9s2ApFvYo892VbX4mNRuWSGsy6Flrsau8ZWjuwc8fkme5V74fGGG7 1RxuXyv1Q8Y4W2gPpX8e4/xrNhs/r6u47SPMNT+2K9UdYes+rtjYQRruzXeFCfRQR4+B zVSTokvw1F/GSpMx2gILcokUryFUD7AlcaesnGd0qk8MG8Co6U77m2Rv1P3tGl016hkB ii4g== X-Gm-Message-State: AOJu0YwrRQGmsYY/Q3p/3oBA2HDmRshu+mOo0mFbqHQ2+I92k6v5bkU7 S8MWEV0noXBGS66P2Wj5Bs59lzSUQ6pzKhBhkpo= X-Google-Smtp-Source: AGHT+IHOvrxz2w5CYyNO3hKwHm2pYG+9+zS/Lx46r+Kby/4xgSo2OCMHT+EaKj3K7S4N0z+T0pmbuC2HqeT4fKDC5OE= X-Received: by 2002:ac2:563a:0:b0:50b:ad16:b5e7 with SMTP id b26-20020ac2563a000000b0050bad16b5e7mr3247909lff.22.1701097427018; Mon, 27 Nov 2023 07:03:47 -0800 (PST) In-Reply-To: <9ac758b8-5fb2-9b3d-7947-96777694e3e0@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12f.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, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=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:313272 Archived-At: On Mon, Nov 27, 2023 at 2:35=E2=80=AFPM Dmitry Gutov wro= te: > But one of the latest emails mentioned a separate Xref backend for c/c++ > -- should I assume that every such backend would define its own set of > *-find-* commands suitable for its languages? Of course, a cross-referencing backend should know what kind of cross-references it can find. Eglot knows how to find 3 or 4 different kinds, language server permitting of course. Eglot will never know how to find "documentation", and I believe the Elisp backend should never purport to know how to find "declaration", since that's a very fuzzy concept in Lisp with no accepted meaning. As is "typeDefinition", doesn't make much sense in dinamically typed languages (but "declaration" is worse). > Would such backends each come with an automatically-enabled keymap? Or > would the user have to set up key bindings for every such command, for > every special backend like that? The major modes could do that, for example. They could do it by linking the backend-created "one key/command" keymap into a special prefix created by xref.el, doing so by calling a load-time xref.el helper. So maybe some backends would have d for "documentation" and others would have d for definitions, so what? Maybe that's precisely what a user working on a documentation heavy system expects "d" to do. And if these two backend= s happen to be enabled simultaneously, even this conflict could be resolved, by adjusting the keymap during the linking process. But however this works, I think the bindings issue is completely secondary. Secondary not in the sense that it's less important, but in the sense that we don't have to commit to something right now, so I don't understand the tortuous route this feature is taking into what-if territory. So whatever solution we find to the bindings issue (if it is indeed an issue) It's much more pressing to decide if/why you want a command named xref-find-all-definitions to return things that aren't "definitions" by any measure or what is pressuring us to enshrine "declaration/implementation/typeDefinition" in one of our most generic libraries. Jo=C3=A3o