From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Adding support for xref jumping to headers/interfaces Date: Thu, 09 Mar 2023 17:36:57 +0200 Message-ID: <83o7p20wdi.fsf@gnu.org> References: <83bklin83z.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22849"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, sbaugh@janestreet.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 Mar 09 16:37:45 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 1paIKu-0005ks-Vz for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 16:37:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paIKS-0003MV-Um; Thu, 09 Mar 2023 10:37:16 -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 1paIKR-0003M4-7k for emacs-devel@gnu.org; Thu, 09 Mar 2023 10:37:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paIKP-0000hh-6I; Thu, 09 Mar 2023 10:37:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1a60f+QeMKa7CB9ZJ6GscX0lUQhi4jYN3MQYEaMkWrk=; b=pGvQGm81fomW V/euNvcqs4Cy/5M40ZftBQ71BfBlBlHFTrUcgRk+6JWZvTW6creIihhzgVuAUtvMejp/ZnvrKk3bA cuTC/diFJj148OkcgwS/JdO/wcnFgh0nmjBKEPoRwMKvRvxWkFgpyrDzDWTpKdLPY89G+GeiCtp/Q ndZGY/VyMuFANYqQTSl3FUe8W9FdGDysKxzvBcpl6Gt06itjrm5UDmUT4iJ9Z6V5ZnH6Tg1yXmVsO pYbdy1HtUFY0HbpbbHHf1Worrn/0mCo7O8uLo0ZJw32DFIkFxmYjrZw+RhfMcHmn1fTdrK9KTk5jL qP7tTIZ5zPoDFLGwWhyeAA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paIKJ-00037q-6L; Thu, 09 Mar 2023 10:37:07 -0500 In-Reply-To: <412afa2d-5dbc-52da-39c4-99be3873929c@yandex.ru> (message from Dmitry Gutov on Thu, 9 Mar 2023 15:04:09 +0200) 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:304209 Archived-At: > Date: Thu, 9 Mar 2023 15:04:09 +0200 > Cc: stephen_leake@stephe-leake.org, john@yates-sheets.org, rms@gnu.org, > fgunbin@fastmail.fm, casouri@gmail.com, sbaugh@janestreet.com, > emacs-devel@gnu.org, azeng@janestreet.com > From: Dmitry Gutov > > > Maybe an easier way would be to have separate tags files for each > > supported category (e.g., one for declarations and prototypes, one for > > definitions, etc.). Then we don't need to change the format of the > > tags file, only make changes in etags, and instruct etags.el to load > > the relevant file as needed. > > What would the user interface for loading the tags look like? I'm not sure we'd need any UI. The command that works with declarations (say) would need to know that the default name of the tags file is TAGS.decl (say), and either ask the user or naybe even load that silently. > Altering our format sounds much easier to me from that standpoint, and > from the added complexity in managing the files/buffers containing > indexes for different types. Is it really that more complex? OTOH, having those in a single file will need Xref to cope with multiple matches, something that currently we largely avoid. You'd have the same symbol mentioned once for declaration, another time for definition, perhaps yet another time for interface, etc. > > The list of categories provided by universal-ctags is quite long, but > > I think we only need to support a small subset of that for our > > purposes, right? That would mean perhaps 3 or 4 separate tags files, > > which might not be unreasonable. > > The granularity in that list seems useful to me, so I don't think we > should try to merge the kinds into some large categories, if possible. > > We might not support distinguishing between certain kinds from the > outset (e.g. between enums and structs, or between macro and function > definitions), and we probably don't support outright a number of kinds > like goto labels, parameter definitions and local variables. That leaves > more than 3-4 kinds remaining, though. My point was that we won't need dozen separate files. How we get to that conclusion, whether by analysis or by synthesis, is less important ;-)