From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Generation of tags for the current project on the fly Date: Mon, 15 Jan 2018 04:44:58 +0300 Message-ID: <259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru> References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> <83shbb30z1.fsf@gnu.org> <8360863o6a.fsf@gnu.org> <27a58fb2-d2ee-e5fc-158d-ec41be401987@yandex.ru> <83y3l0za1f.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1515980598 21985 195.159.176.226 (15 Jan 2018 01:43:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 01:43:18 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 15 02:43:14 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 1eatns-0005IW-Kj for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 02:43:12 +0100 Original-Received: from localhost ([::1]:54135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eatps-0000X4-Is for ged-emacs-devel@m.gmane.org; Sun, 14 Jan 2018 20:45:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eatpl-0000Wf-MD for emacs-devel@gnu.org; Sun, 14 Jan 2018 20:45:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eatpg-0004Cz-Qu for emacs-devel@gnu.org; Sun, 14 Jan 2018 20:45:09 -0500 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:38251) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eatpg-0004CQ-HV; Sun, 14 Jan 2018 20:45:04 -0500 Original-Received: by mail-lf0-x234.google.com with SMTP id g72so6026673lfg.5; Sun, 14 Jan 2018 17:45:04 -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=vx7SqBTkW6WcN3WLaHmmGUNJWNCtiV3kTBrpL1Xl+mA=; b=MfoR5wBxEeiAYg5/FNa+nMNAUj7/yRUJyLmoQquWNlJMEUYF0r2FyXCUo2XS+Y9xq+ inxEyU1rqpv7QU1FqJaQQ++P7cB1JkQOF5t4wdQu6hgwZ+2IY8khpF/puAIDrJvgh7uA zd6EcZLovSn+oR2c2V47UnGBKk/a10s99Xj1CfxU1A1PuRSZIF955S6vPWr1bu6Iot0Z zdVzHs5llRJX4k+oQKi4vPdHKk9sM8DKzbJqe3+Aa4jKQt1heYuMFraxTZw6qs4RElZ7 6OzhuK3UzAVdO9ruh5DlwkduxrxxmB9RArnjM7VXLjSNK4S5GSYFgOx9AzqNtvJJhrdt 9yUA== 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=vx7SqBTkW6WcN3WLaHmmGUNJWNCtiV3kTBrpL1Xl+mA=; b=XDGFEtPpfAMTtMFkKQke0IVsjcXvYn0CbfOXAgip2M2RuOmUNMzl1DV1ExENDB4jP4 iJGcySHfofumb0Wgyq2PYOi+hl1rm/gLMGod12CKRCClFxLQ5x4FlW0DP4yB62+XwIy4 DCl4OZR/Js7JwCDK3kkf2j5BVjwaG9ATE269SdRPnB1iikTjHwh4hvkA2PfZ89W3Ayrp ZBBn8apyndZL7QiKWPzDY9UPF1J75WV4Nz87Sb5RsZ3IhZ+e8Zb++xBnxSmovuqKq1wg Dab+EWpM9qkcf7721ZbEb5pfwA44qz2cNtBVHsnc3YLlEaqDSRCqMCqI6VkOeP67pi1K kckg== X-Gm-Message-State: AKGB3mJLY7z5dzeNd3b2y619yf0mW+wpkF4JWwSrfBCNqUoA3Cr+DPmK IL9bCc9oRxNSRP5lCBds4uM5aR7U X-Google-Smtp-Source: ACJfBouMsNQacNZnEqUVjY4PUz9K8HO827K/X6Cj8knVu/itn2r2hnl7foYeEkzwhzlHFfB/QcJwMQ== X-Received: by 10.46.59.12 with SMTP id i12mr18844965lja.88.1515980702378; Sun, 14 Jan 2018 17:45:02 -0800 (PST) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id 39sm5324298ljb.49.2018.01.14.17.45.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jan 2018 17:45:01 -0800 (PST) In-Reply-To: <83y3l0za1f.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::234 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:221959 Archived-At: On 1/14/18 7:21 PM, Eli Zaretskii wrote: >> OK, so if the user says yes, we "temporarily visit" to auto-generated >> tags table. Then the user saves a file and that table get invalidated >> (or via some other mechanism), and we want to index it again. Ask again? > > No, I think asking once per project should be enough. Until the end of the current Emacs session? And ask again after restart? What about if the user switches to a different project and then back? > I mean the first time the tags table is required might very well be at > the beginning of working on a project, at which time the project > source tree is not yet in the cache. Yes, and? The user will need it to be indexed either way, right? There's also another optimization opportunity: performing reindexing in an asynchronous fashion, in the background (maybe after a timeout, too), after any file is changed and saved. This one comes with its own tradeoffs, though. >> For instance, could you try to see how long takes the generation of the >> file list alone? And populating the buffer with it. But without passing >> it to etags. > > What Lisp shall I use for that? To measure the full time: (benchmark 1 '(progn (etags--project-tags-cleanup) (etags--maybe-use-project-tags))) To measure the time to generate the list of files only: (benchmark 1 '(all-completions "" (project-file-completion-table (project-current) (list default-directory)))) >>> Invoking 'find' will always be faster, as it's optimized for >>> traversing directory trees. >> >> 'git ls-files' will probably be faster still. > > Yes, but that only works in Git repositories. We can probably optimize for that use case these days. Git or some other VCS is usually in place, especially in non-toy projects. >>> No, TAGS is a standard target in GNU Makefile's. >> >> OK, good to know. Two questions, then: >> >> - Can we make it output the tags to stdout? > > Not likely. But you could just visit the TAGS file(s), no? Hmm, there are reasons not to do that in general, but if the way we generate the files is known to be "right", they mostly disappear (except for the implementation complexity: doing it this way and using temporary files in the other case will require more code). How do we figure which files to visit? Do we just visit src/TAGS and expect the rest to be 'include'-d. >> - Can we detect than a given Makefile has a proper TAGS target (that can >> output to stdout)? > > Maybe CEDET has something, but if not, searching for ^TAGS: should be > easy. > >> Not sure yet how to handle the TAGS files inclusions, though. > > "make TAGS" should handle it, as it does in Emacs. So these questions have answers, good. Here's another one: considering the reindexing costs are not always negligible and depend on the size of a project, will there be actual benefit to using the proposed scheme in GNU projects like Emacs, GCC and others (those are the ones that use 'make TAGS')? Or is there a subset of them, at least, which we expect to benefit?