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: Sun, 14 Jan 2018 05:05:04 +0300 Message-ID: <27a58fb2-d2ee-e5fc-158d-ec41be401987@yandex.ru> References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> <83shbb30z1.fsf@gnu.org> <8360863o6a.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 1515895690 29444 195.159.176.226 (14 Jan 2018 02:08:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 02:08:10 +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 Sun Jan 14 03:08:05 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 1eaXiP-0007FY-BG for ged-emacs-devel@m.gmane.org; Sun, 14 Jan 2018 03:08:05 +0100 Original-Received: from localhost ([::1]:56306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eaXkN-0001ww-Gs for ged-emacs-devel@m.gmane.org; Sat, 13 Jan 2018 21:10:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eaXfd-0007RQ-CS for emacs-devel@gnu.org; Sat, 13 Jan 2018 21:05:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eaXfY-00075q-BK for emacs-devel@gnu.org; Sat, 13 Jan 2018 21:05:13 -0500 Original-Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:40442) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eaXfY-00075V-3J; Sat, 13 Jan 2018 21:05:08 -0500 Original-Received: by mail-lf0-x231.google.com with SMTP id v74so7762770lfa.7; Sat, 13 Jan 2018 18:05:07 -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=oyVCW2Qw2GVwuAUNrwj7RPECZIrYMRytpnNpCW47e94=; b=aprkHdE6fDgvRvhIv1haMTvApO0fpqmfmFUSYSg+6cuDkIvqx1ZR+VI1p65vYW778F xuFxlfvov2Zk3JHetUF9u0ZX/cmuFq4giItN6N5HlPahrsVWI6EPESaZsPt1Q+/VPxSP rPdW/81SADPCsEX7fQrOS+Og0hyjeBfywlpiEPKLcOzoEwwq16tpv4cVrkFHJC9o+ANW E8IPB0jkfcVqeFE0ks4oBZr9Pk+5EiStDH2SfyQhB4XAad2je6jepB4NgEGQ9LRR09wZ fq9onw8ChZEohxuDRI9V+EP8DU0iWBOXslzmCMfmXKnk5zbiVxObLLChwOBgtDu4Q+3Q gJIw== 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=oyVCW2Qw2GVwuAUNrwj7RPECZIrYMRytpnNpCW47e94=; b=n9E9UwL4NTuj7qhddBHK35LHx48cRj2uiMiLKD4gwiexOy3iPYVblYg8UqtwN1ftaY x8nFTMuAtaG2D32Nu067aGzwKPQQDcqjGLW3zc4RZdW0dDIsh+DWGNGkaFQXL0L32Fwl tBMfkdsXwz4CqW7kEVpr1TMub48vakeuBfntdb83qQNFCsq9EMi//Og5sjB/uCXrvizu Fu7kZJhhXLALzXj33fJ7z2dpzUXsZANOQkOWHE3uhp597KmPz0tknq0tHjayUfdznMrt L/NWSI8L4zIghPz4YKoLTnta0NittBVi/3tIvmVQDaSb/ohagE1RqtWSiD6yfEZADElV 7F4A== X-Gm-Message-State: AKwxytfH72I9BbUNpmUmnzMqgpbItlkAShSA9962gjRK+ZqZQgScqVse +Srux+hZpEvgvchF1sz0dX2Kat9z X-Google-Smtp-Source: ACJfBotPov1rxUsYZY0Mcdgy6U6dZxDDLefyKUpo2iFSHmlbOLJdKRYJPt91KgwDGNzjPcvmpSaFWg== X-Received: by 10.46.80.28 with SMTP id e28mr1153567ljb.124.1515895506184; Sat, 13 Jan 2018 18:05:06 -0800 (PST) Original-Received: from [192.168.1.174] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id r22sm1055688ljd.78.2018.01.13.18.05.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jan 2018 18:05:05 -0800 (PST) In-Reply-To: <8360863o6a.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::231 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:221946 Archived-At: On 1/12/18 9:52 PM, Eli Zaretskii wrote: > 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. Sure, but not as often as you use completion-at-point, probably. Anyway, what I said was an approximation/simplification. People's workflows are bound to be different. >> 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. If scanning is fast, invalidate-on-save should be good enough. And it's easier to implement (already is). >>> 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. 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? >>>> 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. Not sure what you mean. The tree has to be scanned *sometime* at least once, hasn't it? >> '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. NVMe is a bus for an actual storage device, though. Anyway, 1 second and 4 seconds are different, but not hugely different. And we haven't optimized everything we could, yet. 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. >>> 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. That's a valid argument. On the other hand, they might not know how long the indexing will take anyway. >>> 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. 'git ls-files' will probably be faster still. >>> 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. That's what I was trying to say. >> 'make tags' is very much specific to Emacs. > > 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? - Can we detect than a given Makefile has a proper TAGS target (that can output to stdout)? Not sure yet how to handle the TAGS files inclusions, though.