From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Generation of tags for the current project on the fly Date: Fri, 12 Jan 2018 20:52:13 +0200 Message-ID: <8360863o6a.fsf@gnu.org> References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> <83shbb30z1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1515783129 20043 195.159.176.226 (12 Jan 2018 18:52:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 12 Jan 2018 18:52:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 12 19:52:04 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ea4Qs-0004qK-FM for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 19:52:02 +0100 Original-Received: from localhost ([::1]:59430 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea4Ss-0004wy-4z for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 13:54:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea4RT-0003fR-3g for emacs-devel@gnu.org; Fri, 12 Jan 2018 13:52:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ea4RO-0007T5-BH for emacs-devel@gnu.org; Fri, 12 Jan 2018 13:52:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ea4RO-0007Sz-7K; Fri, 12 Jan 2018 13:52:34 -0500 Original-Received: from [176.228.60.248] (port=4251 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ea4RN-0004Rg-Nm; Fri, 12 Jan 2018 13:52:34 -0500 In-reply-to: (message from Dmitry Gutov on Fri, 12 Jan 2018 16:52:21 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221899 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 12 Jan 2018 16:52:21 +0300 > > On the other hand, code navigation and editing are often fairly distinct > activities, you don't switch between the two too frequently. In my workflows, I do that all the time, because I don't always remember the details of the functions I need to call in the code I'm writing. > > . we fail to find a tag > > Not sure about this one. We can make this customizable, of course > (although the implementation might end up a bit convoluted), but IMO > it's not good for the default behavior. > > Failing to find a tag is a valid result (some identifiers can be absent, > or defined somewhere else, e.g. in the libraries), and doing a rescan > each time that happens might be more annoying. If you maintain that scanning is fast, then the annoyance should be minimal. > > We could offer generating a tags table if we don't find one in the > > tree, instead of generating it automatically. > > And then what? Visit it? No, just do what you intended, but only after an approval. It could be that the user thought she already visited a tags table, or some other mistake. > >> For reference, indexing the Emacs sources takes ~1.1sec here. > > > > Was that with cold cache or warm cache? > > Warm, probably. But that's the relevant time, isn't it? Not necessarily. The first time a tree is scanned could well be the shortly after you start working on a project. > We're most wondering how long it will take to *reindexing* (because > we're discussing when to do it). The first indexing will take place > anyway. > > > "make TAGS" takes about 9 sec here with a warm cache, and this is an > > SSD disk. > > 'make tags' makes 1 second on my machine, with an NVMe disk. I bet it will be even faster with a RAM disk. But we shouldn't base our decisions on such configurations, as that isn't the norm yet, I think. > > IOW, I don't think this is so fast that we could do that without user > > approval. > > The argument here is that if the user called xref-find-definitions, it's > better to do a (long-ish) scan and show something, instead of failing. It could be a mistake, or the user could reconsider given the question. We do that with visiting large files, for example. > > I don't understand why you didn't use the commonly used form: > > > > find . -name "*.rb" -o -name "*.js" ... | etags -o- - > > Because the project API doesn't make this easy. Anyway, generating the > full list of files is relatively fast in comparison. Invoking 'find' will always be faster, as it's optimized for traversing directory trees. > > I think > > using 'find' is also faster. > > find is used under the covers. The difference is just that the > invocations of etags are only happening later. No, the difference is also that in my example etags runs in parallel with 'find', not in sequence. > > More generally, I think doing this that way is not TRT, at least not > > by default. "make TAGS" in Emacs will produce a much richer tags > > table than your method, because our Makefiles use regexps to augment > > the automatic tagging in etags. So I think we should first try to > > invoke the TAGS target of a Makefile in the tree, if one exists, and > > only use the naïve command as fallback. > > 'make tags' is very much specific to Emacs. No, TAGS is a standard target in GNU Makefile's.