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: Sun, 26 Nov 2023 20:30:25 +0000 Message-ID: References: <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> <2d964697-2b4e-64c7-2f16-aae87e57def4@yandex.ru> <87il697r5g.fsf@catern.com> <87r0kw8nxu.fsf@catern.com> <3fe5a8cd-b355-d7eb-10ad-8846aef3387b@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="40536"; 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 Sun Nov 26 21:31:38 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 1r7Ln0-000AOt-30 for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Nov 2023 21:31:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7LmE-0004Eg-GI; Sun, 26 Nov 2023 15:30:50 -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 1r7Lm8-0004EN-OH for emacs-devel@gnu.org; Sun, 26 Nov 2023 15:30:45 -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 1r7Lm6-0005sD-QE for emacs-devel@gnu.org; Sun, 26 Nov 2023 15:30:44 -0500 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50baa2a278bso1687846e87.0 for ; Sun, 26 Nov 2023 12:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701030639; x=1701635439; 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=mh6ikWh+tuzk9d+jhgEwEWG9MzIHL/HXJZnNZmHar90=; b=AAW+3b8X+qb5ydl7pjzLwtERxkT79Kz1j6hXimrvLB1P+HAM4VscdM4sRN012RF/Zp UUgB+q6ouvc6rHmHKfuKc0qbhI9b1EQt+JMD8djtaQCsPrJJSQjuxYBBcf1RUIKqQrJC yH66YoM+sPFybkD73/nYCQVEE73Z1GlZGQGJbzduNoYVq6ckche8/YEdTW5LJTQGoz3G h5cXujGAsgt4WgE9roHCdTFrOkfO6k6D0HuiRcfQ0bV15AW5VwXaMiPyz1cL4yWr2+Gr t2jpm4ctrV/kRvhqVBdW5dAemW3SSirWBCnY1hl+JmpNUPYQS+dkqECU2LXWECxvpjac KB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701030639; x=1701635439; 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=mh6ikWh+tuzk9d+jhgEwEWG9MzIHL/HXJZnNZmHar90=; b=hW2rFELIfM5M+zpI773kQ+NzHtwZ8p9EV/cHPAK3g3J5f0RmY04aoctnvAffTMtbxT MorbAXypg407v+ncI+YRowJOIxYw/KyeoLIVocm4obX/WbE4aFTtBTILst36roR59Qku l6kn+g47ZNQ+QpxH8ghEUZsEtO8MNmf/YiG07+RYnAK5flpk3iTpnIhSlnp+1BSFT5M1 JJJgn+m72usDmqsC4pp2M2gyLGdW8jFgHoI8e6S2b3/te9hXCCPbvM2e8MB6ZhYxRwEO phyfQYy8VYZ8FQtaJAGD33mZtNMn6+n0b7tgL1azJHUS4KdR0lDqsuakja47+sAfwJ93 +6Nw== X-Gm-Message-State: AOJu0Yw5JfenSWA8M4oBJ7Iz4BotR1J/XB5PMjYzvFsBcvr9dQ3VqGOy UvCET1pAhxG2cubprtfWbIzpZLya+EJrgwCsMl0= X-Google-Smtp-Source: AGHT+IH0ZsGeiz/93D4NnRMSyWE0svfvDbtRSyH1EabSh7QGvKsKyafiomyEqmYsi4KnOLYCW8Rpg16uJN4AGxIkdGQ= X-Received: by 2002:a05:6512:360e:b0:50b:ac3f:e44 with SMTP id f14-20020a056512360e00b0050bac3f0e44mr2125574lfs.41.1701030639256; Sun, 26 Nov 2023 12:30:39 -0800 (PST) In-Reply-To: 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:313250 Archived-At: On Fri, Nov 24, 2023 at 1:37=E2=80=AFAM Dmitry Gutov wro= te: > > On 15/11/2023 23:32, Spencer Baugh wrote: > > Dmitry Gutov writes: > >> On 11/11/2023 14:38, Spencer Baugh wrote: > >>> So e.g. c-ts-mode could define > >>> c-find-signature, which has a clear meaning for C. > >> > >> And c-mode will not. > > > > Some major modes will support things which other major modes do not > > support. Users will use the best one, whatever it is, and we'll change > > the default to whatever it is, eventually. I don't see an issue. > > I don't see why we have to limit the users to specific major mode, when > one might have functionality others don't have, and vice versa. It's unclear what you are understanding of Spencer's suggestion, which is also mine. I hope it's clear that in mine and Spencer's view if there is support for a given finding a given thing of kind foo for a given language, then there is an easy command for doing so. And if there isn't that foo, there isn't a command for doing so. This is the way it should be. In my view, again, we should not limit ourselves to a triad of kinds clumsily inherited from LSP. We should limit that LSP concept to Eglot. It is not flexible enough, because it can't be. But Xref is for much more than LSP. > Like now, for example, many will likely stay with CC Mode for a while > because of it more lax behavior in macro-heavy codebases, where > c-ts-mode chokes and shows syntax errors. Whatever you are suggesting, I don't understand. Whatever xref backend is written for c++-mode with its special-purpose commands for finding C++ things can be used for both c++-mode and c++-ts-mode. Just put that code in a special file. > Anyway, I've pushed an update to the same branch > (feature/xref-find-extra). Again, it's something to try out, not a done > deal: > > * The command is called xref-find-all-definitions, with appropriate > behavior when invoked without prefix argument (appends the results from > all kinds and shows them together, with duplicates removed). I think this is a mistake and a regression from xref-find-extra. The command should be called xref-find-all, xref-find, or simply xref, since definition is a category that doesn't span a lot of useful cross-referenceable constructs in many languages. In C++, for one, a declaration is absolutely _not_ a definition. > * The Eglot implementation doesn't include 'references' in the list of > kinds anymore, just because those are not definitions. A mistake, but at least I can roll it back easily. I would like the new interactive "find all" command (whatever you decide) to show me "references" as one of the kinds of thing to search for. Why are you rolling back this useful stuff? Are you even testing? Because the current branch doesn't even work in Eglot. > * New commands for the 3 popular kinds, bound to "M-' e", "M-' i" and > "M-'t". The command which shows all moved to "M-' M-'". A mistake, again. I wonder why you are doing these opinionated changes to the branch you yourself proposed and which I put work into. If you are proposing this is brought to master for experimentation, and if you are wary of this step, then may I suggest we push the older more conservative version, perhaps with some naming changes? This new version isn't something we can roll back easily, while the more conservative approach could eventually be enhanced with the three "popular kinds" later on. > What does everyone think? > xref-find-all-definitions is an interactive native-compiled Lisp > function in `xref.el'. > at point, prompt for the identifier. Interactively, show matches > for all supported kinds. When invoked with prefix argument, > prompt for KIND. I can't get this to work btw. If I add a prefx argument, it prompts me for the identifier, which I don't want. So will you please roll back some of your changes so we can at least get something working again? Jo=C3=A3o