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 19:37:02 +0200 Message-ID: <95afa441-18ae-e62a-be16-be73a545bbba@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> <72b09256-5a1b-8962-9e3c-7d2ffd0dc0d7@yandex.ru> <83ilf925n8.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="22870"; 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 18:37:39 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 1paKCx-0005gy-4H for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Mar 2023 18:37:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paKCW-0004rc-0H; Thu, 09 Mar 2023 12:37:12 -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 1paKCU-0004rT-Am for emacs-devel@gnu.org; Thu, 09 Mar 2023 12:37:10 -0500 Original-Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1paKCS-00004q-73; Thu, 09 Mar 2023 12:37:09 -0500 Original-Received: by mail-ed1-x535.google.com with SMTP id s11so10087103edy.8; Thu, 09 Mar 2023 09:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678383425; 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=+CQNoHFwgX+6tpEYmpEZiDOYDlukJsDaY3qNrm1w9MY=; b=TpnUj4ionFfztd2ZaApCoo/ioZym4R4VUmt7+3uTxb8mCUYK4GsyMMDXmyjsaFo6c+ 4YZeDLti32P7hnfhYGthfogOq+W7t5V8JboB1iTpd1RO0JG3w8zU0k63+YzygzVF6Ehb iHPjo/cbTxOEpQ0zh/H8mYbB/u+qlXpHvNSy2ASbxoywly0WdoW+TsRpwyfGZlnpUK/k 8z5cSqLk+ni4LGsTO7abkl81NZpn3BP2T9fBGa4iJ1Q6bsZkQzhc6sTy2Mxa/AYxTOZv uj3ZBa8Be5d6whL4apVSMlTl9FofEi60dtRO/pcJ6WRGI9I3AonggIw/e6i02tEcnK+g MOvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678383425; 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=+CQNoHFwgX+6tpEYmpEZiDOYDlukJsDaY3qNrm1w9MY=; b=mxVA7COpkFKbIvyDUmxz9WRTbho/9mRxUtPpUidnOLxBGscIu21ahgRt7hpI8DOW04 z9c0VNxtztJyDbDpBLFS99MhPLqYYmIEQRvtjAVOoFO0yNpv7thhqScWjatOtFcHn/Rt x/BBQ9PzIx3mjpZjP0KPHpvO+ecNUxWqlmPSOnccY01DQmT2O/B2+/txdTbjyPPt+fGW 3Z3YEGiAaOF520BhSbHBkmTGrMMvlUlLHrOtiBGy3Wa8VOkqhGco5Y5IjNAQofI9IvFS 0xqO4RsiD8HbX2nTvJUr/QdzJKcXggKw6vICpFeTQeStHX0fc3GfbNnwAT+9zpMeNYMg N3kw== X-Gm-Message-State: AO0yUKW+TxL4ejegpCiBb4ZX9/wW16kvNEIuI4XmMPuJ2Vk+TnXFiKBW q4OvQsTnRCKYYSA2DXrCUq9dw7w2T0w= X-Google-Smtp-Source: AK7set+D7nAFknuA4ACmpOwqXoAy1nrW/LVbk3AoONaF9crjMNhfzgeUXXSP/q7w6D/+K/oVqsKbjw== X-Received: by 2002:a17:907:7fa0:b0:878:6b39:6d2a with SMTP id qk32-20020a1709077fa000b008786b396d2amr30017797ejc.46.1678383425414; Thu, 09 Mar 2023 09:37:05 -0800 (PST) Original-Received: from [192.168.0.2] ([85.132.229.92]) by smtp.googlemail.com with ESMTPSA id v16-20020a50a450000000b004af6c5f1805sm9983865edb.52.2023.03.09.09.37.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 09:37:04 -0800 (PST) Content-Language: en-US In-Reply-To: <83ilf925n8.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::535; envelope-from=raaahh@gmail.com; helo=mail-ed1-x535.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:304221 Archived-At: On 09/03/2023 19:31, Eli Zaretskii wrote: >> Date: Thu, 9 Mar 2023 18:53:42 +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 >> >> 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. > > That's not what I had in mind. I thought we'd run etags several > times, as in > > etags --enums-only -o TAGS.enum > etags --decls-only -o TAGS.decl > > etc. Okay. That sounds like additional hassle for the users, though. >>> 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? > > Only when there's no way around that, and we consider that unfortunate > when it does happen. Sure. But whether we will show duplicates to the user, in any scenario, shouldn't depend on how we store information (in multiple files or not), only on what we do with it.