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: Thu, 9 Mar 2023 18:53:42 +0200 Message-ID: <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> 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> <83o7p20wdi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31459"; 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 Thu Mar 09 17:54:34 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 1paJXF-0007wH-VZ for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 17:54:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paJWe-0000s9-7y; Thu, 09 Mar 2023 11:53:56 -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 1paJWX-0000oa-K3 for emacs-devel@gnu.org; Thu, 09 Mar 2023 11:53:50 -0500 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paJWV-0007tL-LI; Thu, 09 Mar 2023 11:53:49 -0500 Original-Received: by mail-ed1-x536.google.com with SMTP id j11so9633769edq.4; Thu, 09 Mar 2023 08:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678380825; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=2ZT0Hz3KACjiE1oveciwOATNQpVH6fgqhCE/0vCAdBQ=; b=jlaw7O/5W6m1cDOMzhYS0YDFvaD7H2OHXsuIcsBwtmA6hlq2Uy2TAFvJ43vh6Qm03f BYNtBfp/8CvXZqRIdgjOP9E0VjTq/Ci9ltHYX40DuwB/unujZ899Kx5t95nT+g6kf0Mz HEBwOn40CfHdk9wsifs7HSf0kTrG3xeK6x1Z+S3se49rCTPXjdPehuy9F64iKl/6gmd+ AI6a9W97IAoBBVWuAW6D8iwXGnCrW75QPj4tcJ9W1nGZwKuS5EVndu2Gsj7wZHq6rMbA WoySq4tmahOFRyXAx9FjhjTOQvZaB2iUijMIttPPpU9cRmFbu1K0Ke37iaBcMj0nyycv B3gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678380825; h=content-transfer-encoding:in-reply-to:from:references:cc:to :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=2ZT0Hz3KACjiE1oveciwOATNQpVH6fgqhCE/0vCAdBQ=; b=U1iKOP4EDWj/eI5KeB+ygp03odXHw/Bfnujet5l0HDBxiZUwPo6kIi5xqEzpmwbZ1s a0PyLW7EUkleYA94kZT1m/PjlS+gbv9R6p10wCR0x2dpFiv8WpJb6d0ly+kP4pcPXp4b /KhaXfzxcojnoSxefvoWbdEKZli43Qwk18sZPy8LWy976wIe8C/SOqW9qM0unePRcZCL 8uq+0jvuGggFyas9P1e/gkCKgNICsf2Vs8FbDooMH4g3fVrqh3WwHzescndGlKDweYCE RaOIUJe2iG0V8TAraktaoDxiDewS4VG0e+7w8hnP5aUNELgh2xHSznvOV9DuGsNg3+KG M6Sg== X-Gm-Message-State: AO0yUKWDgSh25ymt6GZmN0RyHM27Va8tYefePKXwzqclRc7WjGi5K3Q8 v3NNEod3Mdufza9V8DeNfBJ3ERJTe1A= X-Google-Smtp-Source: AK7set/QDPAb7dJb66vcA2E38PP/ogBjPb3o1hAmGGJkxXpjN8F5gacy/i0AqvyVy2x3/+Y8sRrf0A== X-Received: by 2002:aa7:d29a:0:b0:4ac:c690:d637 with SMTP id w26-20020aa7d29a000000b004acc690d637mr21672075edq.31.1678380825046; Thu, 09 Mar 2023 08:53:45 -0800 (PST) Original-Received: from [192.168.0.2] ([85.132.229.92]) by smtp.googlemail.com with ESMTPSA id v30-20020a50955e000000b004bf2d58201fsm9900755eda.35.2023.03.09.08.53.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 08:53:44 -0800 (PST) Content-Language: en-US In-Reply-To: <83o7p20wdi.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=raaahh@gmail.com; helo=mail-ed1-x536.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:304216 Archived-At: On 09/03/2023 17:36, Eli Zaretskii wrote: >> 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. There is also the issue of having those files generated and saved to appropriate files. If I run 'etags -o TAGS', I might not expect that additional files will appear. Or existing ones -- overwritten. >> 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? The buffer state seems to be the least clear part of etags.el to me. I can easily imagine how to implement the feature the way I'm suggesting, and your way -- not so much. > 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. We already support duplicates, don't we? E.g. definitions of the same method in different files, or even in the same file but in different classes (thus on different lines). The main thing to decide is whether declarations will be included in the list of definitions. But that will just affect the behavior, not the ease of implementation. >> 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 ;-) If it's going to be a file per kind, then let's see how many we could support: d, e, f, g, m, p, s, t, u, v, x. Not a dozen, but almost. Consider also this: someday we might want to stop supporting etags ourselves, as soon as we find an external tool which knows how to scan the same languages and outputs in the same format. At that point it will be an advantage if our output matches the information that some existing tool uses already. Like universal-ctags. Which could extend its TAGS output format to include our changes with little effort. Or yet another approach: we switch to another file format right now which already supports the additional fields: ctags.