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: Tue, 20 Jun 2023 16:31:57 +0100 Message-ID: References: <865ybmu2ha.fsf@stephe-leake.org> <39e25c9a-b4cc-a0ce-3f2a-1d2a1fc243d0@yandex.ru> <83pm9sfxfa.fsf@gnu.org> <861qm4tkih.fsf@stephe-leake.org> <71ea5e83-183f-2ae3-8146-6a31045a0309@yandex.ru> <834jqzafse.fsf@gnu.org> <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> <81c2ff07-c5e2-fb3a-5945-049a307bff84@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="14630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Tue Jun 20 17:33:12 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 1qBdM0-0003Y4-0M for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Jun 2023 17:33:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBdL6-0003xr-Gh; Tue, 20 Jun 2023 11:32:16 -0400 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 1qBdL3-0003xT-TD for emacs-devel@gnu.org; Tue, 20 Jun 2023 11:32:14 -0400 Original-Received: from mail-oo1-xc36.google.com ([2607:f8b0:4864:20::c36]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qBdL0-00050d-Pq; Tue, 20 Jun 2023 11:32:13 -0400 Original-Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-55e4d40794cso1611792eaf.2; Tue, 20 Jun 2023 08:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687275129; x=1689867129; 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=RhI+nL1uXYsLWSqseVExyA0ZD6P5Azk5EJ/4X2y0W9M=; b=dY7aXeG6YGPnY6CsOOV1DuWWMn/xHIqWcUD+mQ/OLENBbb/WJx4BLi8pybk1Ps9NOX nc9kbokNAPa0yKZcqjLOHukkVMSkthwFhKtSYryanibA/Wcvv0yS2GHFOv2CuK8Bzt88 W/gYkXCNjZPaUT1KfMexGVBVOzcWMo88MukGp7lyFlAsX6S/TENxYiA5ybgnnMhbJNjI vi2fYtogzKmrTsMZ4iqErcZuOzZeWSESHLEuE8QqpUxi0Yy4ZNoggHFq+KcbfO9k26VK C95Pt/197iAqELe/vK6m4abnurfT7Rn7x2vK19O6ojLk/2UR1zokVU59pj3C56oOU4Et YeBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687275129; x=1689867129; 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=RhI+nL1uXYsLWSqseVExyA0ZD6P5Azk5EJ/4X2y0W9M=; b=V14k5W9shR/veG2fPk7sCRSalnCL9l2QyzWJNOS4I45AAfQCIK+AjWcPNPPxp0Bptf 1JaY1e14A7//po4flFdHT3iD0Z7EaQppsowvbEC6XSEMO76S4mlCZtcHLoU+dih8wHt3 E51xDIti71YnRh7E5S5xr84NJyKMpjnUo54ys3lUW8PcTfqdOfN9eiQJ38dnvrdv71gp pUc5EDy7Xj4gTzdkvGWhg7m8oMiw2iQDND3fLrqqDvsPjuvC7aiie1YRUlIo32R9kQ+B dZ7OFptZOmr+WWg+aasFbt3HYPT8RzAkRZ+hybiZlwV6LWyz4oAGDlG2dXqnH0VsyNpy bjsg== X-Gm-Message-State: AC+VfDz8ADOLCbaES0iIbeDQxj3FgmNMH9TccLqR8tyEE9TSR8W1CQrc b7IX77PXJqFGdr+u7RSlcGmyLjqKyLm+KmbX/Nw= X-Google-Smtp-Source: ACHHUZ55rXEm7Cz3O+fIkiF4IGsvzexfj6E46sOr/enlfZYbofsYJ1wkzG48nwFfdA5AaQ/i4GKXIwVl/DDEueWhYJ8= X-Received: by 2002:a05:6808:1145:b0:398:4795:930c with SMTP id u5-20020a056808114500b003984795930cmr12049975oiu.48.1687275128989; Tue, 20 Jun 2023 08:32:08 -0700 (PDT) In-Reply-To: <81c2ff07-c5e2-fb3a-5945-049a307bff84@yandex.ru> Received-SPF: pass client-ip=2607:f8b0:4864:20::c36; envelope-from=joaotavora@gmail.com; helo=mail-oo1-xc36.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:307087 Archived-At: On Sat, Jun 17, 2023 at 2:54=E2=80=AFAM Dmitry Gutov wro= te: > It is of course the prerogative of the backend to choose which locations > to return as the list of definitions. Some backends/languages might as > well include interfaces in the list. > > One problem with that, though, is that we're doing some things > differently from SLIME. In particular, we try to make it easy to jump to > a specific definition as quickly as possible. I see no problem with that, but it might be interesting to keep the backend plug-in mechanisms generic enough to eventually enable different types of UI. > If there is just one > definition found with a given name, we don't even prompt to choose. We > also have an option for xref-show-definitions-function like > xref-show-definitions-completing-read which also tries to make things > faster using completing-read. If other kinds of locations are added to > the list, the odds of getting duplicates get higher, slowing down the > interaction. So it's probably a good idea to hide some location kinds > behind prefix argument, or a separate binding. > > That brings me to another question, though. Can we assume that all > "extra" searches should be of the "definition" type? Meaning that the > results display should go through xref-show-definitions-function and not > through xref-show-xrefs-function. If yes (and the ones that have been > brought up in this discussion -- "implementations", "declarations", > "type definitions" -- seem to fit that pattern), then good. If I remember correctly, SLIME (and SLY) have at least two types of "reference" searches: "who calls" and "who expands". They create the typical ((file -> list of matches)...) listing in an SLIME xref buffer. In connection to the earlier comment, SLIME uses M-? to slime-edit-uses, which is similar, but not equivalent to our xref-find-references. Here, if I remember correctly, the xref buffer is built like this: who-calls file-less-function-that-calls-1 file-less-function-that-calls-2 other-type-of-reference file-less-function-that-expands-3 file-less-function-that-expands-4 of course who-calls and who-expands never share an xref buffer. Jo=C3=A3o