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 21:49:02 +0200 Message-ID: <835ybb3txt.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21203"; 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 20:49:57 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 1pZznR-0005Fk-O6 for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Mar 2023 20:49:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZzmj-0000Hc-Ra; Wed, 08 Mar 2023 14:49:13 -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 1pZzmi-0000HS-Kb for emacs-devel@gnu.org; Wed, 08 Mar 2023 14:49:12 -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 1pZzmg-0001zM-Iv; Wed, 08 Mar 2023 14:49:10 -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=9vnFp2/mZnz/pUagnFC7inQNmClsKlO5Yz8nf3s07tg=; b=roiXWjz0pdxD /9AItaZ/FrnUKSAYu40XXXsq3wiL04YRDRIHRMpUDj5mJbmijay9LPHB3hAS0HaAf1H+sSP6DzIhq dS3YSUtoDSqoSUdgPuRRh3EyE7LGxR4av6m9JjKuGAZJhsVfXkbIZQxHWVYZOEe3gvaqTntEx0wTS qdDWfsnM8akTfi+arSa4AmuhqA8oFCKDkQknAmbfQJB+AmclQ//IFlAUsBN7BPlQQ2n/JVd0XTFMZ vj9PiBhHVXdIgKF/ZHgDayQYNS1JVAqraROI9kPICHzcBbyLPgG2ZB3tWrF5ClLSAhLq2I5ki7agY 4kyRR/EwVF+5QMYdfmQGsQ==; 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 1pZzma-0003pE-84; Wed, 08 Mar 2023 14:49:04 -0500 In-Reply-To: <4639d7ca-2109-864c-33c0-38e65f26f262@yandex.ru> (message from Dmitry Gutov on Wed, 8 Mar 2023 20:23:21 +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:304153 Archived-At: > Date: Wed, 8 Mar 2023 20:23:21 +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 > > On 08/03/2023 16:58, Eli Zaretskii wrote: > >> 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. > > etags-snarf-tag doesn't seem to call (line-end-position), at least not > in the latest version. So we can probably add > > DEL kind > > to the end of both directtag and patterntag. > > At least, if I just add "^?f" to the end of a random line, > (etags-snarf-tag) still returns the same value right now. There's more than just etags-snarf-tag that know about the format of the file. If all the rest are also okay with such a change, then yes, this obstacle is down. The next one is to teach etags itself produce those flags.