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: Fri, 19 Feb 2021 16:35:00 +0200 Message-ID: <5de633e5-05c3-d965-e6b1-b8bb91a8f11a@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> 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="14156"; 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 Fri Feb 19 15:37:08 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 1lD6u4-0003Mp-Kx for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 15:37:08 +0100 Original-Received: from localhost ([::1]:45256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD6u3-0004jp-NQ for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 09:37:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD6s8-0002xb-I0 for emacs-devel@gnu.org; Fri, 19 Feb 2021 09:35:08 -0500 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:34373) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lD6s6-00074C-L4; Fri, 19 Feb 2021 09:35:08 -0500 Original-Received: by mail-wr1-x42d.google.com with SMTP id n4so8853020wrx.1; Fri, 19 Feb 2021 06:35:05 -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=EvZFD8sG64kjo2FVN1WjijZ1ilUByzbW1MVu7kH7rWY=; b=H5d828VOAKa0VTQRjDG4/RwRPN1VVZCYnyf8HyOLbmENrr0hZP82oVQW4tLuUKr19I dgu81+Y1E42z123JAXUI+mO/SscTMj5XXiZrN1q6r5yMCJBEN28O/fHEH78djGz2XA2j PAG3sq4IpfJ3BPWhjGnQVVnV9vJQ/KD2NM0kjsYIgGlJN/wL4uQ+WDR/doI70WEi0Zye E5n75leO7p9eoJVdAKIg+usJnk8ZTEZK9mmuFtV+f7QkTMLjoJmYGO7oo4Gli1XXBimB exvlKu/W+GhIcWw3jPBbZQvLnpYAJnVvU6mefLDDClS2B1+QxwwIw+bGW7rulXSnR807 zKJA== 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=EvZFD8sG64kjo2FVN1WjijZ1ilUByzbW1MVu7kH7rWY=; b=PqAih898//jL/yPeU4J+T1RxKV6jwLPHOqQI8eYOjhcHi+uPw9hq+hrleYRIQvTjB0 gP3nUrU+g3uGhvZG9eFVjbtCyQM0ihQeyX/PoysLBBZWRzOqLam4PheEAKLP70wk2gBf orHdV70TewM7YKbT2TS8ki082NbEYetSOORAll2af8I5pPAbWjo8X+vx8crRXJS7CP5g sxBB812Xb9Y6dULg7Ssr3SRL5NLJ3Iq/QCsWppsVdHmZKvpskLG1kQbEvdAgGxQbPn3H JNYnmgbvlud31KetCnCbTsJ9UfAOQ+ncg0w77CbQN15I0TvTB3Kh+pG6P+IkAfjZWBMr yzaQ== X-Gm-Message-State: AOAM53345kqfxklxXvG3vKRB078SqP/1vRHyVrnV3sB/ZPx1waGTh8JQ L4ZSwdeJOW60mchPjkAn2rMhtDLnpeY= X-Google-Smtp-Source: ABdhPJxYZ5sKicK4QAfYRpTmOrmk6JMEl5cbXZTMC4FIV46HFcwWOrvHzhC8RFndg7c1kBDeMRz4Yw== X-Received: by 2002:a05:6000:1378:: with SMTP id q24mr9361658wrz.421.1613745304836; Fri, 19 Feb 2021 06:35:04 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id o1sm10366013wmq.8.2021.02.19.06.35.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Feb 2021 06:35:03 -0800 (PST) In-Reply-To: <838s7k4ft8.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42d.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:265260 Archived-At: On 19.02.2021 10:33, Eli Zaretskii wrote: >> From: Dmitry Gutov >> Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org, >> emacs-devel@gnu.org >> Date: Fri, 19 Feb 2021 01:26:43 +0200 >> >> On 07.01.2021 17:56, Dmitry Gutov wrote: >>> - A change to lib-src/etags.c which implements handing of '-L' flag, for >>> compatibility with ctags. >> >> How do you feel about cherry-picking this particular change to the >> emacs-27 release branch? > > I don't mind in general, but: > > . this lacks the proper documentation (we should at least say that > -L is for compatibility with ...) and NEWS item Sure. I was hoping you might do that, as someone more familiar with its documentation, but it doesn't sound too hard. > . it should have a corresponding long-option name, and thus should > be reflected in longopts[] Any suggestions? ctags doesn't have a long variant, just '-L'. --list-from-file ? >> Or if you don't, how do you feel about that code change at all? One >> alternative for me is to try to support both 'ctags -e' and 'etags', >> with some ad-hoc version detection, I guess. Then the change won't be >> needed. > > Sorry, I don't think I follow. Can you elaborate on this? Well, there are several options before me: - Only support Emacs's etags. Given the momentum behind the universal-ctags project and the fact that 'etags' is often an alias to [an old version of] ctags on users' machines, that might be unfortunate. In particular from the "working out of the box" perspective. - Apply the patch I posted and support only the latest etags, as well as all known ctags versions. Only to an extent, however: the way etags-regen-lang-regexp-alist is applied is dependent on the '--regex=' option syntax, and ctags yet again has a different one (--regex-). So either this option won't be supported with ctags, or etags will need another change for compatibility, or... - ...We add a setting for "etags vendor" and two different code paths anyway. In this case the '-L' compatibility will be moot as well, adding this extra flag - or not - can easily depend on the "vendor" option.