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 16:27:45 +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> <869c25b8-4c99-fb35-cd8c-b1a8a6256e04@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="10858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , John Yates , Ergus , =?UTF-8?B?RmVsaWNpw6FuIE7DqW1ldGg=?= , Filipp Gunbin To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 27 17:28:58 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 1r7eTh-0002ae-ES for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Nov 2023 17:28:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7eSp-0006el-21; Mon, 27 Nov 2023 11:28: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 1r7eSn-0006dh-Rh for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:28:01 -0500 Original-Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7eSl-0005n8-TT for emacs-devel@gnu.org; Mon, 27 Nov 2023 11:28:01 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-507a0907896so5771121e87.2 for ; Mon, 27 Nov 2023 08:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701102478; x=1701707278; 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=YrSqwCvBbpwKTibjruFQJWmaLSWCBXjQIhLBKe1PYB8=; b=V01wBVV45tOz9xZADoqVmut00DlNu/tikMJNFHiUFTSuttbf+SnhThguknqR8gHYSV N3pZ254hnh1AtfJmFmB1bytQlLSH5SrK+H4sCOB8fscIDi4ShIoigXD5/pYVdc1Z6ven W5ods3mWB9Zv2GmbZmjyUYzCiwPDcReg7pCi4QDEOIxBS+Jg3Asb6D1UgUrHQJzl270J rHqnjgLJksUc3/ry/t1qOJSzRqFeCjkqBf1qlKgBPtAjrv8WEGgqPeEDRqAzTTVveenO f8pg8yv+Z8B85jNS3/xasX2bW3Lg+s7OmgpD5kufRmJvO73OVSRkuWCvAin9ft8/Enn8 ArMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701102478; x=1701707278; 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=YrSqwCvBbpwKTibjruFQJWmaLSWCBXjQIhLBKe1PYB8=; b=X52cAejFZiZYCF6KbJDLvX+fOh5GP3Ms50OhB5k4oE9vCmK7Q9TqBjxLUF/XoWg4ES JqJQDK2y3+mnpXgOlA4IuTo+YWJNTOvaZzDMrmKxeliEGuzgP9ufJq5F2s47qDCBPcS2 DUwbrkDlECxWJjACnHpzNKcdquumLJTXpX2ZcdIA3ms5A2kNA4MaTz9dx4BNTdczvcNs C0+sjZT719HnttydlDlg82DDbljKvMTtLtBdWYptiwTmnLvtiJvooyuZxJuPYbfaAIJc sutw51Ghd7Ee/FUSIERehmdyvfduCeS2I8s2VZ9/FJ/zUTfcGTiNvu8KghdNiN1BMwQC 0AEg== X-Gm-Message-State: AOJu0YxYTOKqxPSt9DEw9HF0XLd7sq1VeI4YbjOXkisV3Ekme422Ehte FO/SIl+vE/FfLKDe9G6mMSdY+ZmMAGOhZKVgvXU= X-Google-Smtp-Source: AGHT+IF6NWrbogLsDb4edgTOCP5yOZlYGQuojcJih7f0VNXDqMAZSWAH3XgbgktyLtizzHOT8rD+YHNqX8DlZ4lZrDI= X-Received: by 2002:ac2:428a:0:b0:50b:aa88:c54e with SMTP id m10-20020ac2428a000000b0050baa88c54emr4370993lfh.16.1701102477417; Mon, 27 Nov 2023 08:27:57 -0800 (PST) In-Reply-To: <869c25b8-4c99-fb35-cd8c-b1a8a6256e04@gutov.dev> Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x134.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:313283 Archived-At: On Mon, Nov 27, 2023 at 4:04=E2=80=AFPM Dmitry Gutov wro= te: > Why don't you read up on the difference between > xref-show-definitions-function and xref-show-xrefs-function. Those are > not implementation details but something that affects user experience. > And users can customize one or the other, which correspondingly affects > dispatches which go through one or the other. First, who does that? I thought you were concerned about the OOtB experience for non-powerusers. Secondly, if something called "definitions" is used for things that are patently not "definitions" that thing is incorrectly named, period. It's not because that editor thing was misnamed by its creator that magically my C++ declaration is now a definition, too. > >> Further, I'm not sure that when a user looks up all definition-related > >> things for a symbol, they wouldn't want to see the "declaration". In > >> fact, if we classify 'defgeneric' as declarations and 'defmethod' as > >> implementations, I'm pretty sure I would want to see the former in the= list. > > > > Of course, if the world is painted in the three LSP primary colors, > > every other color will have to be truncated to that. But it doesn't > > mean the world gets any prettier. > > Would it be better if the user has to type 'dec' in C mode but 'defg' in > emacs-lisp-mode to get to a semantically similar set of results? They're absolutely NOT semantically similar, only very superficially, like, yes, most users of this list are vertebrates. I don't mean to be pedantic about languages but there's really a world of difference between a C declaration and the things you can say with a DEFGENERIC call, or what their specific intended purposes are for the language designer. Any user of these two languages (C and Common Lisp) languages will know this very well. In my 15 years CL experience I've known exactly 0 people calling defgeneric forms "declarations". But I presume you're talking about completing-read? I would type 'dec' in the first and 'gene' in the second and so would probably the masses. But the list is so small, I'd probably just scroll down one or two positions. > >> And you yourself mentioned that "type definitions" might be suitable f= or > >> that list (which I found surprising at first). So it seems clear that > >> there is no single red line. > > > > Precisely. So don't go making those lines. > > > >> o show me "references" as one of the kinds of thing to search for. > >> > >> Then the list of results would drown in "references", wouldn't it? > > > > But if I want to see references to the given symbol at point, that's wh= at > > I want! I press M-? xref-find-references all the time in Eglot. > > And that's great -- please continue to press M-? for that purpose. > > But if 'references' joins the "definition kinds", then the command to > "find all definition kinds" will become pointless. And we already have > command to "find all references". No, not pointless at all. My main use case for this is to first invoke the command on a given place of interest and _then_ ask myself what I want to see of that symbol. "All references", "definitions", "declarations"? > >> For experimentation. > > > > Then perhaps we could cut another less contentious branch off > > 279203199a2d10677e42747476b39394a4184a78 > > > > Over that branch we can rename Eglot kinds to strings and "extra" > > to "all". I'm sure that's less contentious, a good candidate > > for master and not incompatible with evolving into whatever > > results of your experimentation. > > See above. So, awright. Do you really really want to rename "extra" to "definitions"?? is that the blocker? Makes 0 sense, but if there's no talking you out of it then I guess users like me can swallow the awkwardness and translate "definition" to "thing" in their minds. And we have strategies for renaming things anyway. > > Well I am, but not of that code, at least not yet of that code. > > Merge to master something useful that doesn't compromise us. > > We're yet finding that. What exactly is compromised by that patch? And do you not agree it is minimally useful? You wrote the thing! Noone forced you to. > What about showing the combined set? Sure, that can be done. Just have xref invoke the generic function for as many kinds as the backend reports.