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: Automatic (e)tags generation and incremental updates Date: Sat, 20 Feb 2021 22:27:50 +0200 Message-ID: <25073978-eb02-4f40-4104-9d18df87def0@yandex.ru> References: <779a6328-9ca5-202a-25a2-b270c66fe6dd@yandex.ru> <8fc5e96c-ebb8-c668-9b2a-c7c4ee54c0b9@yandex.ru> <83r1mwltob.fsf@gnu.org> <0bee9ab4-46bc-b6fd-97b6-e26cc80f1610@yandex.ru> <731c1b21-b3e9-89fe-3751-9c2a528adfba@yandex.ru> <838s7k4ft8.fsf@gnu.org> <5de633e5-05c3-d965-e6b1-b8bb91a8f11a@yandex.ru> <834ki82hbh.fsf@gnu.org> <67d2bd44-032d-f014-338f-387a07503d9c@yandex.ru> <83im6n19it.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="23030"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: philipk@posteo.net, tom@tromey.com, emacs-devel@gnu.org, john@yates-sheets.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 20 21:29:00 2021 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 1lDYs7-0005pj-U0 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 21:28:59 +0100 Original-Received: from localhost ([::1]:38202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDYs6-0001Xy-Vs for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Feb 2021 15:28:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDYr8-00011x-Ce for emacs-devel@gnu.org; Sat, 20 Feb 2021 15:27:58 -0500 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:46907) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lDYr6-0002AC-7p; Sat, 20 Feb 2021 15:27:58 -0500 Original-Received: by mail-ej1-x62e.google.com with SMTP id gg8so11078123ejb.13; Sat, 20 Feb 2021 12:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FOIFFMunACjax98EP3dyjHibL4TjHSIQPeP0nLEpRDM=; b=PxRag2n5tGNqdjOwsqNEePjjSHtrF2gOq/CMNfnOLYMAavWRIjyqqKGeXOUEQ0NYWl XLO7T94WVTB1mEfzifduFII2aQZx6c0u5wNju57CHmuHKxpD31K3yL5XVG7JGdTgN/xn B7uS2WUG2Wv8aafpBPLAWaZfDlNfBugk3TjFfJP1Q/IEnw7nB2foEkSnHbVVB4yIhgiZ IURn4ojsGx26XpjjK6304MmHmbHSJf+o3xe+dlPvm9SYBoZvpLG9xwdvL71tYUv0sbqr 0MzBxa/nX2glqirDWGu6NYEama0fodLAq7VyNAtjRmn3FN+tYEQRoB467UZt5TeEvIyr Pb3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FOIFFMunACjax98EP3dyjHibL4TjHSIQPeP0nLEpRDM=; b=uCjpG41g+9olRVD9G+SjicUpQ/d7QYqK8yV33cAU/yU0Mf9Hsp8T7dRhGd7JDCuBr5 nKDsU2oFMEdJwhfjyJU0fUkYnIVP34AKsYVb8V1KQHkpKIbhSYan8lZS8oZicEH8RgEI 4eGmvb3EkoL98DziQhAuX98IK07Sy7HCTbv4rSfZLbRvtLM9+hQ7HC8LdsRzKLBhhHP+ ZpnRy9eXbNbRBRmhVCyKkvgiA0lVG+RziAXxFJtAgyltliHpzWZN89uxPdmZRZCgcVNm 5QDWBFxaEP2MCEZmRC7oJLDRbZ214+ghKEEEU0l5+BDEAfd64r7LnZjef+Fk2A8O9RJ6 bI9w== X-Gm-Message-State: AOAM532XRo8FrRjyKGnAUgO3XoS+2oVB0RdUF/O2OBfn7O/5n0op+I4w OmltKIJFz2qlMzWIJAPlZGXDQKbU+Zg= X-Google-Smtp-Source: ABdhPJymu5u/Y/bIY+HgdSm0i2naneXcczKs31/i1RZjAFVgnbOHWU5gFSUV7YtU9ypsaRMK8rOm+w== X-Received: by 2002:a17:906:17d3:: with SMTP id u19mr15068823eje.316.1613852874105; Sat, 20 Feb 2021 12:27:54 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m21sm6261644edq.86.2021.02.20.12.27.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Feb 2021 12:27:53 -0800 (PST) In-Reply-To: <83im6n19it.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=raaahh@gmail.com; helo=mail-ej1-x62e.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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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.23 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" Xref: news.gmane.io gmane.emacs.devel:265353 Archived-At: On 20.02.2021 09:30, Eli Zaretskii wrote: >>> It sounds like a fully compatible code is not really possible, so some >>> test to detect which etags/ctags program will run, with the necessary >>> code tailored to each of them, seems like the best COA in the long >>> run. It's a bit more coding, but the differences are fairly minor, so >>> I don't expect that to be too hard. >> >> It's one more source of bugs, because I would personally be using only >> one of the code paths on the regular basis, and the same might be true >> for emacs-devel regulars who might try it out. > > But below you propose a compatibility layer anyway, for the regular > expressions, right? So the danger of less testing and more bugs still > exists under that proposal, AFAIU. And the compatibility code for > using "-L -" vs just "-" is very simple, so why not put it under the > same condition as what you plan for the regexp compatibility? That would work quite differently: etags wouldn't have to launch an external executable and somehow guess whether it supports some flags. It will just add for support some new (common) ones. And if etags-regen will exercise just a limited set of them won't result in any kind of instability in the package. Or should not, at least. There is still some risk, of course, but that would stem from possible differences in the implementation of said options between etags and ctags. >> But in the long run, it might be good for us to have a better level of >> compatibility with 'ctags -e': less user confusion, for one thing. And >> for best results, I think we should approach that compatibility from our >> side (if we do at all), rather than wait for them, because older >> versions of third-party software will be around for a long time, but we >> can more or less be sure that Emacs comes with the latest version of etags. > > Maybe I still don't understand something: how would "compatibility > with 'ctags -e'" be different from what is discussed here, including > this: Same thing. That's why I'm asking for it, right? >> FWIW, -L plus a compatibility layer for --regex (translating >> --regex-lang=abc to --regex={lang}abc) should suffice for etags-regen >> for the near future. >> >> And support for --langmap, maybe (does etags have a counterpart for it >> at all?). > > The equivalent of --langmap is "-l LANG", I think. (We could also > teach etags to support --langmap directly, patches welcome.) If such patch materializes, any chance we could put it into emacs-27 as well? Then I could use some pointers: for example, which stdlib and/or utility functions you would expect one would use to add this feature. Just the names could suffice.