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 15:04:09 +0200 Message-ID: <412afa2d-5dbc-52da-39c4-99be3873929c@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> 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="30777"; 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 14:04:51 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 1paFww-0007kQ-Og for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 14:04:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paFwQ-0001WX-TZ; Thu, 09 Mar 2023 08:04:18 -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 1paFwO-0001WM-Qy for emacs-devel@gnu.org; Thu, 09 Mar 2023 08:04:16 -0500 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paFwM-0006Ml-RR; Thu, 09 Mar 2023 08:04:16 -0500 Original-Received: by mail-wm1-x32b.google.com with SMTP id l7-20020a05600c4f0700b003e79fa98ce1so1192657wmq.2; Thu, 09 Mar 2023 05:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678367052; 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=YHvvDmhzvpoVwLb8i+4TzRg2EmbS+kUxGZ6fCXvyWXs=; b=ScvwcexhHKWEAjaKO9m988nuzDgXAA98ZXDF2/3Kx0WHtLXEFZ0rO4PnHcLf7dMRcC KzfuDoF54Gz4UQTm7Jqtr/v2ADupb2i4LyWLUX2XBTaq0pkWdSf64es7GGORzPjXhrLb Uuti//3UzhDbN7qk4Pp9o5eEgKRunc6n4SxL1BAW29BMTr9vLPrWDosuxtR8nHOxHf7C 4bjRtSw00z9/aZ+WMvydSHkh9Ijm6/6qhjt2vVShfO6CCldh2qprDdnBkUcnXn6t30Kv +IbeC2tfK9N9F6pfAsyFIf/iwUKAD3iSrKJ7BM8ggojP1NVPfqanKfVVhxC6HBNXBffx vMCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678367052; 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=YHvvDmhzvpoVwLb8i+4TzRg2EmbS+kUxGZ6fCXvyWXs=; b=bPGw1W/3/yvCDRY6k6Q2lfybzVIKMNVjepCZnQFIksxmAIt9QjX004vFpbBaI2UZ9O SYEI7J942puRaUNMGBxWQyPBJssfbJaT/ZHKldlgV9TUjseXSAQ1/nsbcCQUcUJJ3719 HOLqfCvaXfRO5/oCXqmUeTvgKGCJmGKs/TsdnZbx5HoXlJWz8quOgKDrWB6FHxcWH1FF w6phmA9MSqWKZA+7ETHfFm+U4b2VJ6J5ShFsgxc+VBzO75Ft4n6rNNZRakix2z7qgrn0 hKogBBsSGMD+hCcRIZg0lU/S67GQMkNkxSOHlklmfZ54Sy7d1O51F3sQQPfyYqHXiInw qzgw== X-Gm-Message-State: AO0yUKXNNatM6R1E9IG/A20qxwpPmo3Hezl3V7Wcq/aCyKgIRIMVVWYr zTVzuFZ5EdZkpRSIX99uur0cjhqXJ7s= X-Google-Smtp-Source: AK7set9eFByGt7KHjopqPC8S/dVegKJIQz7HyBns8/kgl9TIgr0fckDAgo/slvI8C2YdJT3J9qKidQ== X-Received: by 2002:a05:600c:4ec6:b0:3eb:1ba8:7cfc with SMTP id g6-20020a05600c4ec600b003eb1ba87cfcmr19407786wmq.30.1678367052118; Thu, 09 Mar 2023 05:04:12 -0800 (PST) Original-Received: from [192.168.0.2] ([85.132.229.92]) by smtp.googlemail.com with ESMTPSA id r1-20020a05600c35c100b003dfe5190376sm2720902wmq.35.2023.03.09.05.04.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 05:04:11 -0800 (PST) Content-Language: en-US In-Reply-To: <83wn3q311i.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32b.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:304199 Archived-At: On 09/03/2023 08:13, Eli Zaretskii wrote: >> 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. What would the user interface for loading the tags look like? 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. > 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. The granularity in that list seems useful to me, so I don't think we should try to merge the kinds into some large categories, if possible. 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.