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:19:50 +0000 Message-ID: References: <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> <77500777-aea2-14db-4aab-7a5dff43443b@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="404"; 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:20:53 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 1r7dPp-000ASu-MK for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 16:20:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7dPE-0001KZ-Pu; Mon, 27 Nov 2023 10:20:16 -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 1r7dP4-0001Ji-Kh for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:20:06 -0500 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7dP2-0000xp-EL for emacs-devel@gnu.org; Mon, 27 Nov 2023 10:20:06 -0500 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-507a5f2193bso4401078e87.1 for ; Mon, 27 Nov 2023 07:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701098402; x=1701703202; 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=s4R4LQvA+0QGJZvg/7c6l3y3QvbWyvVwQJZLJo1mJdI=; b=EYVemDvAWOZf4Ky1PKqKWamIkXpWLgSP/HFn/g20cAFT3zEKqX1a1d0vdBopw0Wxbv z6EFCIeCCxxp3WUtmjUR9/R3rAcEMlUTQ8XOuTQOn3U24rjOAanQOln3NyS5HF9XVs4z 02K2i5l27Q9vk9cXXNZCNpvCw4Y5DZzZdCKHcFr3wQ1TtvgS3NZgvlEESAoeXv6XRcg9 6zVDqB9p0IPNCBb6a94OfE+S3pdIod6yV6eis0RZ4/YmtuFBI+zH/i4kwwh1EskLlm5d suV2vOfPBgIw6VSVktyday42URUiitHE/iFAtvKWBLc7q3xYdzGgyW0QEcYs1Kgk23Jt fMNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701098402; x=1701703202; 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=s4R4LQvA+0QGJZvg/7c6l3y3QvbWyvVwQJZLJo1mJdI=; b=HzLJSHHB99ekBb36SkmKieBLhkixtqGKMlyXWRPq6DPjEvu468+1zPOe9+gw2/x2SK rNon+KL5riTfWMRiLiEKvZRezZSjhoWD47DBtJ7vdTPd/43k2JBpXcKvQGfdwhnrmyGu RNnAEhGHjoVz7BhC9Sfdl6S8uI4Cy9lAh9M6vcFI8rxUu8mprHhhfzO0HYmi0Q0wwbO2 H4zTV2jRav+Q2FFUhgucGEMQOCOmpvop2EjjDxZUPalQlFOgDiJ8+Mc+fytTHHO+8Erw OGVbLVqInmx8kw9iU4v6Gey+QpZenOdau0J435on/pjMnpkh1hnR1Cp1tRJ26kojoakT L1aw== X-Gm-Message-State: AOJu0YxNoVaM/QLSIN8puIEUhoLRDpUe9WHqtLOVViQURUSkFH88L2my QnSQm3yV69LXkDdz/2oKF2waRMQVrP+xQtvitEtSHCIZ8lQ= X-Google-Smtp-Source: AGHT+IFFbBCac/2rGm4XZpymhz7KUZxYWiaZraM/z3m8IYbUwit+vxnSECM/1bzocp7usNp9BZuwGFv0GHQ5Am7qtPI= X-Received: by 2002:a05:6512:3c89:b0:509:4d3f:a1c4 with SMTP id h9-20020a0565123c8900b005094d3fa1c4mr4116597lfv.12.1701098401997; Mon, 27 Nov 2023 07:20:01 -0800 (PST) In-Reply-To: <77500777-aea2-14db-4aab-7a5dff43443b@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x136.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:313274 Archived-At: On Mon, Nov 27, 2023 at 3:02=E2=80=AFPM Dmitry Gutov wro= te: > > On 27/11/2023 16:49, Jo=C3=A3o T=C3=A1vora wrote: > > On Mon, Nov 27, 2023 at 2:43=E2=80=AFPM Dmitry Gutov = wrote: > > > >> (that's what the completing-read approach is for), and whenever we fin= d > >> out that particular kinds get supported by many backends (or by most o= f > >> the available/popular ones), we could "pull them into the core", addin= g > >> a global command with one binding which would work across languages. > > > > Alright, so since this is contentious (who else but you is pushing > > this idea?) > > Indeed, I wonder if nobody else is interested in having the additional > commands have pre-defined bindings, or having the same bindings across > languages. Of course if you put it like that then EVERYBODY is interested in that. Everybody likes consistency, but this consistency you're proposing is a mirage. An naive Xref user would be very proud to use "xref-find-declaration" in 3 different languages but then would start to doubt xref that the things he and the backend author meant by declaration are entirely different. Again, leave this to major modes, which is what we always do (or to backend which in 95% of cases would live in the major mode when they are language-specific). > > what about we start with 0 in xref.el. We can always > > add to 0, no problem, but taking away from some other number > > isn't so easy. > > We could indeed start with 0, but then I already see the same set of > extra commands supported in Eglot, Elisp, lsp-mode They only exist in Eglot and LSP-mode because these are LSP things, it makes full sense they would exist in any Emacs/LSP interface. Elisp? What commands are you talking about, only if you force them. I see no elisp-find-{declaration,type-definition,implementation} or anything of the sort. The 7 Elisp cross-reference kinds you defined in your original patch are "defalias" "face" "function" "constructor" "generic" "variable" "feature'" This is exactly what a language-specific kind list should look like by the way. These are the interesting things to cross-reference to in Elisp, not "implementation", "declaration" and "typeDefinition". Sure we can squint very hard and try put those into those three drawers, but it's such a meaningless exercise with no practical value. > >> and to allow frictionless extensions for special capabilities. > > > > As to frictionless extension, the macro I proposed already > > xref-define-finder seems the easiest way by far. > > Sorry, I can't find it. > > But the definition of xref-find-declarations takes about 3 lines. There > is not much potential for making it even shorter. It's very similar and analogous to: (defmacro eglot--code-action (name kind) "Define NAME to execute KIND code action." `(defun ,name (beg &optional end) ,(format "Execute `%s' code actions between BEG and END." kind) (interactive (eglot--code-action-bounds)) (eglot-code-actions beg end ,kind t))) And allows us to control exactly the 'interactive' spec of such commands to give us consistency among them. Jo=C3=A3o