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 11:01:06 +0200 Message-ID: <83shbb30z1.fsf@gnu.org> References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> 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 1515747962 15580 195.159.176.226 (12 Jan 2018 09:06:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 12 Jan 2018 09:06:02 +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 10:05:58 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 1eZvHb-0003Lk-G4 for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 10:05:51 +0100 Original-Received: from localhost ([::1]:55178 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZvJb-00077r-4C for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 04:07:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZvDQ-00035w-9U for emacs-devel@gnu.org; Fri, 12 Jan 2018 04:01:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZvDL-0008Ip-BD for emacs-devel@gnu.org; Fri, 12 Jan 2018 04:01:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZvDL-0008IO-8V; Fri, 12 Jan 2018 04:01:27 -0500 Original-Received: from [176.228.60.248] (port=3664 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eZvDK-0003IN-M7; Fri, 12 Jan 2018 04:01:27 -0500 In-reply-to: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> (message from Dmitry Gutov on Fri, 12 Jan 2018 04:02:06 +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:221880 Archived-At: > From: Dmitry Gutov > Date: Fri, 12 Jan 2018 04:02:06 +0300 > > Here's an idea I've been working on. We generate tags for all files the > current project contains (except the ignored ones) when the user calls > one of the xref commands, but hasn't explicitly visited any tags table. > > The result is used until they make a change in a file somewhere and save > the buffer, then the generated table is discarded. Why discard it after the first save? The tags table is probably still very much valid. I'd not discard it until either of the following happens: . we fail to find a tag . the user visits a tags table explicitly . the user switches to a different project(?) > I think it will be helpful for new users (who don't really know how to > generate tags), as well as people who are used to certain other editors > performing the indexing automatically, in small-to-medium sized > projects. With some effort, we could implement re-indexing and > invalidation on a more granular level (so it's usable in bigger projects > too), but transitioning to GNU Global would probably be better. We could offer generating a tags table if we don't find one in the tree, instead of generating it automatically. I think this would be a better UI and UX, especially given the time it could take to generate TAGS (see below). > For reference, indexing the Emacs sources takes ~1.1sec here. Was that with cold cache or warm cache? "make TAGS" takes about 9 sec here with a warm cache, and this is an SSD disk. On fencepost.gnu.org, a (somewhat slow) GNU/Linux system, it took 12 sec with a cold cache and 4 sec with a warm cache. And Emacs is not a large project; I wonder what would happen in larger ones, like GCC or glibc. IOW, I don't think this is so fast that we could do that without user approval. > + (extensions '("rb" "js" "py" "pl" "el" "c" "cpp" "cc" "h" "hh" "hpp" > + "java" "go" "cl" "lisp" "prolog" "php" "erl" "hrl" > + "F" "f" "f90" "for" "cs" "a" "asm" "ads" "adb" "ada")) > + (file-regexp (format "\\.%s\\'" (regexp-opt extensions)))) > + (setq etags--project-tags-file (make-temp-file "emacs-project-tags-")) > + (with-temp-buffer > + (mapc (lambda (f) > + (when (string-match-p file-regexp f) > + (insert f "\n"))) > + files) > + (shell-command-on-region (point-min) (point-max) > + (format "%s - -o %s" etags-command etags--project-tags-file) > + nil nil "*etags-project-tags-errors*" t)))) I don't understand why you didn't use the commonly used form: find . -name "*.rb" -o -name "*.js" ... | etags -o- - Doing things the way you did raises issues with encoding of file names, which could cause subtle problem in rare use cases. I think using 'find' is also faster. 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. And perhaps we should also provide some customization for the command to be used (but that will obviously not help newbies who didn't yet customize the project they are working on). Thanks.