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 08:13:13 +0200 Message-ID: <83wn3q311i.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6272"; 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 07:14:35 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 1pa9Xu-0001PS-12 for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 07:14:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pa9XF-00008b-0q; Thu, 09 Mar 2023 01:13:53 -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 1pa9XB-00008Q-Pp for emacs-devel@gnu.org; Thu, 09 Mar 2023 01:13:50 -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 1pa9XA-0004hs-95; Thu, 09 Mar 2023 01:13:48 -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=0CCzNlM/ScIvXnPdqmsNNh302SFfN5FsSZwz/p41f9k=; b=PkDp5qx9XWWW nP4h2hWOBTFUI/mlhwOlrG80dzbuLwygdpn+4BQ/5UKJhziOLgB9hQz64y8kl6zSFlxLrvGfS+yFl /mQDqkVjTc6P85diWBTxSInCm6Y/WXL9K9jM3OJs33hjA5VZ+p6v7E0KbubKxLk98ig317UbrhFaQ L9urs2MBPlHt/KEKsAom75TD+k8sKaBaGGlXN5U1i63rDL/j0+vzgC7Ds+rhTV3yjmRaDtox5gF2+ 2/SGR5aUZAJWT37NssuqLuHFMRLhdtdAR5MxKJ1J1LnjUdh1dB0rqJFSX1QG6+cyRTpoL7RP+6eZl 76Pam6NeGlc4eMDR08aDIA==; 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 1pa9Wd-0003yy-P0; Thu, 09 Mar 2023 01:13:16 -0500 In-Reply-To: (message from Dmitry Gutov on Wed, 8 Mar 2023 22:15:18 +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:304161 Archived-At: > Date: Wed, 8 Mar 2023 22:15:18 +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 21:49, Eli Zaretskii wrote: > > If all the rest are also okay with such a change, then yes, > > this obstacle is down. > > Hmm, tag-implicit-name-match-p uses the $ anchor in its regexp (line > 1652), seemingly unnecessarily. That condition can break. > > I suppose that we could ensure to only produce explicit tags when kinds > are added. > > Or add a new switch to etags which would add kinds, default to off. Then > the new feature would be supported (by etags backend) only for users who > made sure to generate that info. 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. 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.