unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: philipk@posteo.net, tom@tromey.com, emacs-devel@gnu.org,
	john@yates-sheets.org
Subject: Re: Automatic (e)tags generation and incremental updates
Date: Fri, 19 Feb 2021 17:44:19 +0200	[thread overview]
Message-ID: <834ki82hbh.fsf@gnu.org> (raw)
In-Reply-To: <5de633e5-05c3-d965-e6b1-b8bb91a8f11a@yandex.ru> (message from Dmitry Gutov on Fri, 19 Feb 2021 16:35:00 +0200)

> Cc: philipk@posteo.net, tom@tromey.com, john@yates-sheets.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 19 Feb 2021 16:35:00 +0200
> 
> >    . 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.

If you need help with this, I can help.

> >    . 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 ?

SGTM.

> 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-<lang>). 
> 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.

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.

I also don't mind adding -L, but from what you say it will not be a
complete solution anyway, so what do we gain?



  reply	other threads:[~2021-02-19 15:44 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14  3:36 Automatic (e)tags generation and incremental updates Dmitry Gutov
2021-01-07  3:46 ` Dmitry Gutov
2021-01-07 14:15   ` Eli Zaretskii
2021-01-07 15:56     ` Dmitry Gutov
2021-01-07 16:17       ` Stefan Kangas
2021-01-09 21:49       ` Tom Tromey
2021-01-10 13:53         ` Dmitry Gutov
2021-01-10 16:56           ` Tom Tromey
2021-01-10 19:39             ` Tom Tromey
2021-01-10 23:09               ` Dmitry Gutov
2021-01-10 23:36             ` Dmitry Gutov
2021-01-10 23:50               ` Dmitry Gutov
2021-01-11 14:56                 ` Eli Zaretskii
2021-01-12  1:33                   ` Dmitry Gutov
2021-01-12  4:21                     ` Stefan Monnier
2021-01-12 16:59                       ` Dmitry Gutov
2021-01-12 17:24                         ` Stefan Monnier
2021-01-12 15:08                     ` Eli Zaretskii
2021-01-12 16:48                       ` Dmitry Gutov
2021-01-12 17:15                         ` Eli Zaretskii
2021-01-12 17:32                           ` Dmitry Gutov
2021-01-12 17:55                             ` Eli Zaretskii
2021-01-12 22:26                               ` Dmitry Gutov
2021-01-13 15:01                                 ` Eli Zaretskii
2021-01-13 15:52                                   ` Dmitry Gutov
2021-01-13 15:58                                     ` Eli Zaretskii
2021-01-16  3:57                                       ` Dmitry Gutov
2021-01-16  7:34                                         ` Eli Zaretskii
2021-01-10 16:49         ` Eli Zaretskii
2021-01-10 16:58           ` Tom Tromey
2021-01-10 17:56           ` Dmitry Gutov
2021-01-10 18:14             ` Eli Zaretskii
2021-01-10 23:13               ` Dmitry Gutov
2021-01-11 14:53                 ` Eli Zaretskii
2021-01-12  1:49                   ` Dmitry Gutov
2021-01-12 15:09                     ` Eli Zaretskii
2021-02-18 23:26       ` Dmitry Gutov
2021-02-19  8:33         ` Eli Zaretskii
2021-02-19 14:35           ` Dmitry Gutov
2021-02-19 15:44             ` Eli Zaretskii [this message]
2021-02-20  1:35               ` Dmitry Gutov
2021-02-20  7:30                 ` Eli Zaretskii
2021-02-20 20:27                   ` Dmitry Gutov
2021-02-20 20:41                     ` Eli Zaretskii
2021-02-20 21:05                       ` Dmitry Gutov
2021-02-20 21:14                       ` Dmitry Gutov
2021-02-21 19:53                         ` Eli Zaretskii
2021-02-21 20:39                           ` Dmitry Gutov
2021-02-22 16:08                             ` Eli Zaretskii
2021-02-22 19:25                               ` Dmitry Gutov
2021-02-22 19:33                                 ` Eli Zaretskii
2021-02-23  1:15                                   ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834ki82hbh.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=john@yates-sheets.org \
    --cc=philipk@posteo.net \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).