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: Wed, 08 Mar 2023 16:58:23 +0200 Message-ID: <83h6uv47e8.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21242"; 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 Wed Mar 08 15:59:25 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 1pZvGH-0005Jl-4f for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Mar 2023 15:59:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZvFf-00062M-II; Wed, 08 Mar 2023 09:58:47 -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 1pZvFd-00062B-Kf for emacs-devel@gnu.org; Wed, 08 Mar 2023 09:58:45 -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 1pZvFb-0000Fw-Lo; Wed, 08 Mar 2023 09:58:43 -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=BnDvPsEZwjnznZTw2XNa/QWDPqCfClbF/DS6Vuyo1b8=; b=Tqkj7acd2ZTJ VnY9ao5V35fZk8KLPLtJt3ib5+tGW/NQLrtue3FX/Sj6fNlHrE/5kgk0b2lKyAqtT1ftvcKdXmoPY sGGc/R/OIo/RksoRU/KoZujBY0QUWDryQ+0liD9QqS1NayB3G2BN5ZBZr2gOYfI8QBTAR749UNEmq BISFpaI+JQM1SZKGlC1DZxFTslh75Zv4aKv/hlzQOmoJGaBwDuWBI6OVqQE7VwAYH6DxCZectONo/ ceEV9syuKabOtLkWZkE2XwplOqfqJdqo/kksTBFORbiA6m9WpE8CbKscWuhcnlglGXGDOfgKSrx1F svk5VJUu6iW/ODojZjIUlQ==; 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 1pZvFK-0000na-5O; Wed, 08 Mar 2023 09:58:26 -0500 In-Reply-To: (message from Dmitry Gutov on Wed, 8 Mar 2023 00:41:49 +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:304137 Archived-At: > Date: Wed, 8 Mar 2023 00:41:49 +0200 > From: Dmitry Gutov > 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 > > After 'sudo apt install universal-ctags', I can see this: > > $ ctags --list-kinds=c > d macro definitions > e enumerators (values inside an enumeration) > f function definitions > g enumeration names > h included header files > l local variables [off] > m struct, and union members > p function prototypes [off] > s structure names > t typedefs > u union names > v variable definitions > x external and forward variable declarations [off] > z function parameters inside function or prototype definitions [off] > L goto labels [off] > D parameters inside macro definitions [off] > > That seems to mean that it can distinguish "function prototypes" and > "forward variable declarations", although their scanning seems to be > disabled by default (can be toggled via --kinds-c=+p+x). > > So I suppose the question here is how hard it would be to add to > existing etags parsers something like that, and whether we can extend > the TAGS format in a backward compatible way with this info. How do you envision a backward-compatible extension of TAGS format to support such flags? AFAIK, TAGS doesn't distinguish between the tags by their kind, it just records all of them, and leaves the semantics to the program which reads them. The current format of TAGS is described in etc/ETAGS.EBNF, in case you didn't know.