From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Felician Nemeth Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Sun, 26 Nov 2023 17:08:06 +0100 Message-ID: <87sf4scxax.fsf@betli.tmit.bme.hu> 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> <878r6mx1xc.fsf@betli.tmit.bme.hu> <90e4b9a7-3b51-587d-e317-b89e5d5464d9@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="27327"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cc: Spencer Baugh , emacs-devel@gnu.org, Eshel Yaron , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , John Yates , Ergus , Filipp Gunbin To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 26 17:09:15 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 1r7Hh2-0006m9-8S for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Nov 2023 17:09:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7Hg6-00010i-ME; Sun, 26 Nov 2023 11:08:14 -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 1r7Hg4-000109-KY for emacs-devel@gnu.org; Sun, 26 Nov 2023 11:08:12 -0500 Original-Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7Hg2-0004wG-W1 for emacs-devel@gnu.org; Sun, 26 Nov 2023 11:08:12 -0500 Original-Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a0064353af8so867865666b.0 for ; Sun, 26 Nov 2023 08:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701014889; x=1701619689; darn=gnu.org; h=content-transfer-encoding:mime-version:face:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=umMdUwklQGD4XFdG8GyIiPZX8havAYZkyR+muyw7S7w=; b=Tme8jDKGRBHeRn9OnAMbjXYenr92ISF7F8GLnfWjYHFsfu4f8jRvp3LAYI6YCM7Qvc qCU/zUUviuSnh/x7ZhPR4b4qIqUFtwbkh/VL7azxe+W+0b+cK65c3nOBb6XQol0hlA42 akifz/qT334xoy2vn1OnKXT1sP5BYNmg+vUppQyBEPnbdWCoIuMYU640C6PpilXoinn0 +qpv+BxN/C2Px9HAQfo1/Zoq318cXZzwPunxozjheJ6jQX7iWuxmNaDMTQQm716XQN/i 2FkGjpw6C3RBNJXYKvAo/xafr14dpqy2WdeCretrs0pMU18hsvE2mFCOEfrEv3BncKmq GP4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701014889; x=1701619689; h=content-transfer-encoding:mime-version:face:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=umMdUwklQGD4XFdG8GyIiPZX8havAYZkyR+muyw7S7w=; b=vvBbVzBUisoOwML4hJ0J0eBp3qY9uv+OB+Amd8fgRkKO6Cn/2lHqy0q/2O+gPFvYob tOV1Lg5mTZneK2LD4WcjRTCLtE0sz4KH+JNSFm48wZPb+NObbXVPgDx/UaePrxw7MdLv ZeiwYMUN9y+ano8+EF/oy+KutXnBRsAaLXd1VSrRVTteEyS/Aw4uTcnlBd0V7du19bAo PdIWOHI+Oy1hl4bGy/Rxqt/rjJweLcbxbzYFPEVJG64Y/ukGL8wekJEwI/H+fpsB+EbM fZ/7IJQtUk1QHDyvYXagk00kjzhrdddvN1Vr2DZQux6kb/2fE6ATIFWyTr/DacX/bp9l UfKQ== X-Gm-Message-State: AOJu0YydrOdEyBJKWYdoThwhCtT7B3EcFeDinGPMDVoV7XfKC5WJVKDz CGwU2DbVjavOZM5S8yfE2Ls= X-Google-Smtp-Source: AGHT+IFjzFIRJPxo/nacu9YcNi7R/5/nRRPa09q+8QxxCtAIdO7rF9saGlk6gpJv+VipRYQTfjaxuw== X-Received: by 2002:a17:906:2259:b0:9ee:a767:12e7 with SMTP id 25-20020a170906225900b009eea76712e7mr8967936ejr.6.1701014888780; Sun, 26 Nov 2023 08:08:08 -0800 (PST) Original-Received: from betli.gmail.com (catv-89-134-210-182.catv.fixed.vodafone.hu. [89.134.210.182]) by smtp.gmail.com with ESMTPSA id u17-20020a170906069100b00992ea405a79sm4650083ejb.166.2023.11.26.08.08.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Nov 2023 08:08:08 -0800 (PST) In-Reply-To: <90e4b9a7-3b51-587d-e317-b89e5d5464d9@gutov.dev> (Dmitry Gutov's message of "Sat, 25 Nov 2023 04:20:47 +0200") Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEU2EgDVmFNHKAa4dz4q AwCDUSH2zWrE61tmAAACeklEQVQ4jU2UwY7jIAyGEZN5ABSFc9Ytcx6K6DmqmHsD8tyZKrz/I+xv yI6WKlHlj982tomiVckiWrUrgRU5jlqMpJKCkch5W419DQAiQGHDxdrWmm0/2kXCApiUmrZLq20s cjexq3VL25QuxjY7wOcJVEpb+jLeGLAK+OMyaa1hx9rFbkwHFWBVA2y8w1wHaLE7GuDdw5cEuOM5 SLIdrpwBkN0ezwI7nYoiilqthbcYc89KgC5+NnaOHGbZz0T6BCEgOLJ0vmYXuNdPAIXgDZJhF2Yu fjnPNwAsoUTUN/P8q3AAyz4zB/xmifEfiIbvS4jh7b7QqZiSm4MJC5kXNpCRaOsoyQXAMN2XCJfs j94NKfo7ACKUEgKE3y+Sg4jibUZ1A0jgYpxtvYMC3gHaHPq6x32ACeALIZoZxB+l9VrRNIA1ncRg wwC8pvQIvYO+a2yt3VXMVyli6L0VV6aOrJa4CpilVQA+eHt0xavk61akih5BUMay/0BAqu783C5h FifY/3QsAIoWYk6PgpwAzLI652+96e2IfN2cF+BD1uT23F21Ghh5OUl4RlO15oh5A2iv+Zk2wsjZ 2DtB5Sm3A4P0+kyb2vs4iEW7G9ohoN3Stl2kVat6MCkXldo6OKaE8P6GhmrKKxWZXQH1iklhhn+d iVeNf6mDdkV0ltFwApRbp+kXSGBFHGV2aPqnIIyQyzhD5n47khqKI08bIapcas4O+hPkct20NAEv ALRuZFUp3PrnQSAm+4lTdHCsYYZ/nGqQrM5z3NS3zefFxkfFPRFbsjpIfbTlvF3ibpVZQ9nzqv60 F/KXSRLJ1AGappJulZll70N/qz6EfwEOCdYOuTHAzAAAAABJRU5ErkJggg== Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=felician.nemeth@gmail.com; helo=mail-ej1-x62b.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:313242 Archived-At: Dmitry Gutov writes: > Here's a refresher on the points of contention, in case you'll have > something to add: > > 1. Whether Xref should have separate commands for > declarations/implementations/type-definitions. With default global > bindings (probably -- if we manage to get agreement on taking M-', for > example). Or e.g. have a registry for kinds and letters, for quick > selection between kinds (alternative for completing-read). Or just use > completing-read and leave the definitions of all new commands > (including the counterparts to > declarations/implementations/type-definitions, of which then there > will be multiple copies of) to the Xref backends. I have a completing-read-function that creates a single keystroke selection, so the two alternatives are almost the same to me. However, in the past it made sense to find the first xref backend that knew the definition of an identifier. Now let's assume backend A provides definitions with letter "d" and backend B provides documentation locations also with letter "d". I think it useful to allow the user to select between the two when xref-find-all-definitions is invoked. And it is easier to create a flat list for completing-read than for read-multiple-choice, for example: ("definition/A" "documentation/B"). > 2. Whether Eglot should, in time, deprecate its corresponding three > commands if Xref adds its own versions. I think one of Jo=C3=A3o's design goals of Eglot is to rely on existing Ema= cs features as much as possible. > 3. How the new command (currently named xref-find-all-definitions) > should behave: should it always ask for the kind, or have a default > one (determined how?), or fetch all kinds by default and show them > together, like the latest version does. I don't have a strong opinion about this. In elisp-mode fetching all kinds by default seems to be the most useful. Usually there are no more than a handful of items and it is easy to see their kind. >> I think it is a minor inconvenience that it is not possible to use >> directly the symbol-at-point as identifier while asking the user for the >> kind. That is a prefix argument causes xref-find-all-definitions to ask >> the user for both. > > I'm open to suggestions. Using 'C-u C-u' for one of the choices? > Adding a separate command with different behavior (and different > binding)? If I'm the only one who'd be happy to have this, then a separate command without a keybinding would be fine.