From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Sun, 5 Nov 2023 00:43:49 +0200 Message-ID: <437001d9-4aa6-a80e-ee42-78000a0c5465@gutov.dev> References: <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; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7481"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 04 23:45: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 1qzPOH-0001fn-GG for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Nov 2023 23:45:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzPN0-00069p-Ev; Sat, 04 Nov 2023 18:43:58 -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 1qzPMy-00069V-Eh for emacs-devel@gnu.org; Sat, 04 Nov 2023 18:43:56 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzPMw-0000ez-Kw for emacs-devel@gnu.org; Sat, 04 Nov 2023 18:43:56 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1FB285C009E; Sat, 4 Nov 2023 18:43:52 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 04 Nov 2023 18:43:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699137832; x=1699224232; bh=wxQDHKwXcv7z3W5LH54LtOSodvliXiN28Hc 4Cx1nxQU=; b=iHpQ6B24omB0f8Y74d8bvq3coULG6xk8wREEmAXzah9ZpSnciRO aYuxYpZ5XA+ShNT2q77+yK3mpj6n2/UHHMWuWASBnO9EIYP+1Q6P3MDkzG83SlxZ hn9teCFiELidmyFdrlCQa7gWgTB8y0M7QVgj4vOBYn5g4TAhvtZbvU+riK8dHJ+f purAuX2zFh3nTO9opXXqRt9u/Y0y7THFrGrE6za1bpUdfI1DrPLUi1ltaPBnacPf KZDRWLXrW90CZhPnvP87VRYPXGgt9LDM14LNRQ6aHK3ipp9gW7agk21kc06viM0B vmgD4d/e9RHdBRsK8IsNhZ0Sk42yxDoOhEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699137832; x=1699224232; bh=wxQDHKwXcv7z3W5LH54LtOSodvliXiN28Hc 4Cx1nxQU=; b=gL2V6KNksr3k8mN7VGC84wWCC4JNM3CVcYB78Sn99DDxu3XjShu bXFZ3Gjzp9dZGSvwaj8eVv4g1VTvsOBffF6aKuFINNNzPZt6dwxF3dlBvTAbONrv mMYgzd4doxyiX2GpxncCpo6t0yytSOaPgP+AoXCkp76Tw2IyT9eMsR+gYRMdxXUQ wSUD50IW1hQr/sXKJsf3X+IhxF0a6Rw/laNIZwoxv/HEKYCx4r6bYtOA/rDbLabf PyvccsPQK9bfHyb7L4x5qQtVYYpOQjkLmUVE7Id5H/Mtd3ZZ1t379oCXVgm43AOc WyxrXvkd+sY6YpeNIuPRIlXnEdFlk+ttuLg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduuddgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 4 Nov 2023 18:43:50 -0400 (EDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -58 X-Spam_score: -5.9 X-Spam_bar: ----- X-Spam_report: (-5.9 / 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, NICE_REPLY_A=-3.137, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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:312229 Archived-At: On 23/06/2023 18:03, João Távora wrote: > 2. if we're willing to add another level of hierarchy to the current*xref* > buffer and segregate results by file and category instead of just by file > as is done currently. Or make this configurable so the user can > segregate just by category. Or present the category as a tag. Many > ways to skin this cat. Adding multiple levels of grouping is definitely an option. I'm not sure it's ideal, though (usability issues like +1 extra level of indentation, and if there are enough elements in a group, you scroll down and don't see the group's heading anymore unless you make it "sticky"). Note that actually Elisp's find-definitions output is already "annotated" with categories: the first symbol in the summary (defun/defvar/defface/cl-defmethod) unambiguously denotes the definition type. I wonder how often that is the case with the other backends. Maybe Xref backends for C/C++ (etags/clang/lsp) just show the line where the definition resides, which depending on the style might or might not include the beginning of the definition. I think for those langs, the main cases where there would be multiples definitions, is in the case of inheritance (also in Java), and it would either should the definition in a superclass, or definitions in subclasses with overrides. In Java, at least, those would be usually disambiguated by the file name (conventionally, they correspond to class names more or less 1-to-1). All that aside, a "sufficiently smart" backends for any of those languages would be able to render the Xref summary string in any fashion they want (for definitions, the summary doesn't need to copy any physical line). E.g. prepending "@override " for overrides. Not sure how realistic that is for LSP, but something more rough could likely be done. E.g. specific words attenuated with color prepended to the summary for the "special" definitions. [type] . Something to try out, anyway, if