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: Wed, 8 Nov 2023 23:22:07 +0000 Message-ID: References: <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> <65a16247-1b1a-149c-b413-71612f88f184@yandex.ru> <9377bf2b-13ed-8d86-4294-0b88e6808d80@yandex.ru> <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> 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="27317"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eshel Yaron , Spencer Baugh , Eli Zaretskii , stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, azeng@janestreet.com To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 09 00:23:19 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 1r0rtH-0006we-BL for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Nov 2023 00:23:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0rsP-0006Zk-Kv; Wed, 08 Nov 2023 18:22:25 -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 1r0rsO-0006Vr-Nk for emacs-devel@gnu.org; Wed, 08 Nov 2023 18:22:24 -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 1r0rsM-0007ek-N2; Wed, 08 Nov 2023 18:22:24 -0500 Original-Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5098e423ba2so143340e87.2; Wed, 08 Nov 2023 15:22:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699485740; x=1700090540; 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=yn+SCYPWuFud2wEk0GK2aWNGaaV+pZhLe+PbaIz+1PM=; b=a6O60AnaYdeiCut+7CMKPhYIlmKQgHpv52rfZz/W4NUEnM/gQ4fixFUZtjeyT5oqZq QJ7PtwmMEBqdYZeAvZt/IHWLnfYTYaAWCo0pdDRz5Zi8dIYl0QBDtnGhrxKrC0Lyosth lvhSF89elBayNVWeDXTAk5gSkJLuSLUwayqLIqJGIHBpx0Ztg+iTmU3y2VPmMLNQEGqC iEQxxLGrBdkEL6Lh+8f2uPURWflywUSUnpOp0x51UmAT1HiHviTMcCQcwgTOEwf0gWOM Rcv5xxmAue6wAARXklM7fXOUbZMI3WBhiYCW+4xoZs+DtbD5eYl2BlgHjQcWYhUdR2pe DnUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699485740; x=1700090540; 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=yn+SCYPWuFud2wEk0GK2aWNGaaV+pZhLe+PbaIz+1PM=; b=OgC6uUaxjXurWsLY/GSSunLgVtDrZNwnzrweZI+9PTkP8uyiklAe8Wfe1rwxxFrvEz /d1aHT4s0w9bdUWcUC56N+gfmbIhbhOfzK3XHnxpK+OFtj7nnNhsembFHVrBtUvVy3Dk FyMNbLORg/QcSay8QFFFKHxYZ5+KLO8MNatrn+fmMAHlj+7svHOxU5xBKLf+mv8o99HI wvrfF09+Q0ZUWtklENIKhqENCnIQLJkveBjAHmgrtoQFMIejpWd4j7BbiiapOnzV6BY2 lJ66uBATN2YYughKruGSkRgljOZEaY34SmxlxP4DQvMd7EoVvbf/l/CKZRObJEvZ6FXn 2dAg== X-Gm-Message-State: AOJu0YyudwbkFi4OFVSsYJoRc+rRjaq/9fVfPZsRbZTXM7dcz31cDIFH 8EnrEQ9gYkFjcbzcijm85I4wGmBKrx2uxGbeaLQ= X-Google-Smtp-Source: AGHT+IE1PSWf3suzvp7cqqdKisq02OywGRjafERW0LonnDSs4Un/TLFQUy4ZuACu2vwmrTtNeMIXJNP8EW3ky3+prYE= X-Received: by 2002:ac2:530c:0:b0:507:b87f:c61b with SMTP id c12-20020ac2530c000000b00507b87fc61bmr15679lfh.66.1699485739911; Wed, 08 Nov 2023 15:22:19 -0800 (PST) In-Reply-To: <953056ea-9cfb-34ad-6515-9036633dfdbb@yandex.ru> 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:312368 Archived-At: On Wed, Nov 8, 2023 at 10:59=E2=80=AFPM Dmitry Gutov wro= te: > > On 08/11/2023 03:19, Jo=C3=A3o T=C3=A1vora wrote: > > On Wed, Nov 8, 2023 at 12:33=E2=80=AFAM Dmitry Gutov = wrote: > >> > >> On 08/11/2023 02:21, Jo=C3=A3o T=C3=A1vora wrote: > >>> On Tue, Nov 7, 2023 at 11:18=E2=80=AFPM Dmitry Gutov wrote: > >>> > >>>> Joao didn't want to have such definitions in Xref. I'm still on the > >>>> fence, personally. > >>> What don't I want? I haven't read this wordy subthread but it seems > >>> Eshel is proposing exactly what I changed in xref-find-extra: take "k= ind" > >>> as argument. > >> > >> Sorry: you didn't want those definitions in _Eglot_. Not in Xref, that > >> was a mistype. > > > > Ah. Well, first, it a fact that I _have_ them in Eglot, and I'll > > keep having them, because they've been there a long time. > > The normal practice is to wait a little while until the new "core" > feature is available for a lot of users (perhaps skipping a few Emacs > versions, or - more bravely - wait for the next one and then just raise > the minimum xref version required), and then declare the built-in > versions obsolete in favor of the upstream. > > The period before obsoletion is not as important as the agreement to do > that - because then we will be talking whether the "proper" > functionality should be shaped as a number of new commands (one per > kind), or a dispatching command, or both. Or something else. > > For the purpose of such design discussion, simply using Eglot's commands > is not a good choice. I don't get this talk of obsoletion. I don't want to obsolete anything. The Eglot commands are there because they fulfill a need that generic xref.el commands will never be able to fulfill. > > And it's not really relevant that I didn't _want_ them. If I had > > the choice back then between recommending existing xref commands > > and adding new commands to Eglot, of course I wouldn't have added > > them. But I hadn't, so I did. Pretty simple. So I don't understand > > the argument you're making against Eshel's and my suggestion. > > Since you didn't want them and argued that they shouldn't be in Eglot, > it seems natural to assume that you would be happy to obsolete them in > favor of built-in functionality. You assume wrong, or at least it is not something really relevant to this discussion. If xref-find-extras had been around at the time, I would have argued that users could use that or simply that xref command-defining macro to make their own johndoe/find-thingy commads. Or major modes could do it, perhaps even better. But neither was available at the time, so I did those commands and they won= 't be obsoleted any time soon. > >>>> Or it would be nice to hear from someone who have tried out Eglot's > >>>> integration and found more upsides there. > >>> If you want that to happen, the only realistic way to have good > >>> feedback from anyone else other than emacs-devel nerds like me and yo= u > >>> is to release an Eglot version with this feature, which we can chang= e > >>> later (even non-backward-compatibly, within a reasonable time frame). > >> That seems like a last-resort type of approach, for this particular > >> discussion. > > > > Not really, just being pragmatic and suggesting a way for you to > > get the opinions from Eglot users that you wrote you wanted. There > > isn't a significant amount of engaged Eglot users in this discussion > > that are going to try the patch. > > Feedback is good, but I prefer to arrive at some sound design first, > even if it doesn't do everything anyone might want. And then test it on > a wider audience. The base of the current design, the xref-backend-extra-defs and xref-backend-extra-kinds, is more than sound enough. IMO could some micro-enhancements like better names and support for non-string kinds, but that's completely secondary. I also think the xref-find-extra you created and I tweaked is pretty good. completing-read is definitely the correct choice to select the kind. Not clumsy at all IMHO. But the ideas you've been offered (by Spencer?) about enhancing it via a prefix argument or extra variable to ask for all kinds all at once are pretty good too. And you can do this later, probably even backward-compatibly. Jo=C3=A3o T=C3=A1vora