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: Wed, 8 Mar 2023 00:41:49 +0200 Message-ID: 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> 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="20091"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 07 23:43:02 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 1pZg1M-00054N-MT for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Mar 2023 23:43:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZg0Q-0005yY-Fj; Tue, 07 Mar 2023 17:42:02 -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 1pZg0P-0005xl-5n for emacs-devel@gnu.org; Tue, 07 Mar 2023 17:42:01 -0500 Original-Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pZg0K-0006GZ-LF; Tue, 07 Mar 2023 17:42:00 -0500 Original-Received: by mail-wm1-x32f.google.com with SMTP id p16so8750168wmq.5; Tue, 07 Mar 2023 14:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678228912; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=QQBu/k6rjfBYuE1KgKu2V1bvmxjX7txoOhIsO/qBOFk=; b=oOMLxyGphldYFUtuQuFIKUxVy2e5s2unpCaoOeOJpPihkDCct0jW4GPncCySn0l/vP fzHr0JaG7veReHncyDwcStceDWANy8g/1AbInBbCf/Q7amgWV761wOpTmQ2Xe76Q1U3F o/iEPyJt1fZVmiyxhWdP9/hvRqGn4Z91IvEW/SW5rTpn1b068uxXTEBR4ifJ68ZAKJaY FY1MWe1aKTSJTl0PxgiDQAWL0Oc2jxJV+RXvlUyOQ2SpqSJEcCA50MSMbzNPFGtulSfR 7cEE3fqPyuGovkeH8HYRhZ9QvQLKAXrWCKqurAteRVeQLvkhFiMWTw/3hxiA8zENZjEw 4r6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678228912; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QQBu/k6rjfBYuE1KgKu2V1bvmxjX7txoOhIsO/qBOFk=; b=RHcKkmM1UvOj36pDdaaW+0wsIcDNBTJOY8lhE6Wfv/MA+BP7Pjs6EgfwscDPS6sS/V Ba7bE1RyEIIDYDtuNI7wIqjV+zwsBGOYP924kdOfXG7bNJ3+4naIA4ruXf0k9lQJUxZ/ 0QAIi5mxKjZ5KhmEIpZbHJTqZbD1BqOLrLx9SV+jOl8vd5LgoJCOB0aCjEWlzg0+2rpO I/+RKD4WfACu8NdPFCNFLEyzJPRSDxwrP4zhUMtsInXlwM32s6feUjMIkI+jj6cW2N4c JqlEbTS+2Qohcdfi87PzeO+ohUu5h2m505VuIL0A0bfnDJzi0DfVDJpbYOjOF7Gh6a2Q 8NwA== X-Gm-Message-State: AO0yUKWWAicLIIblu8pxh62JH8lAhh9OxpiyH/h8jGoIANKnn5Dd5QJ4 3ZdhkmApxQ1djAesobb70Cbm4Vumdqs= X-Google-Smtp-Source: AK7set/gbiVlFwYh5c6Mfkn7rZSxDi2Z6A0zXtFc4zF66Aa0mJpwMsAuAdvmBh/PvPBVPcdzYokF1Q== X-Received: by 2002:a05:600c:4fc3:b0:3eb:3b7e:7b97 with SMTP id o3-20020a05600c4fc300b003eb3b7e7b97mr13586642wmq.30.1678228912558; Tue, 07 Mar 2023 14:41:52 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l3-20020a1c7903000000b003e7c89b3514sm17418782wme.23.2023.03.07.14.41.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Mar 2023 14:41:52 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32f.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:304096 Archived-At: On 05/03/2023 14:06, Dmitry Gutov wrote: >> For C-like languages, we'd need to run "etags --declarations" on *.h >> files for that, I think.  And the resulting TAGS table will have stuff >> other than just declarations, so we'd need some way of distinguishing >> between them and the rest. >> > > The etags xref backend usually works with pre-generated tags files. So a > way to distinguish between them and the rest would be best. To expand on that thought: Universal Ctags has a bunch of extensions for the output -- in particular the "kind" field. 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.