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: Fri, 9 Feb 2018 12:41:33 +0300 Message-ID: References: <4559858d-eb32-d071-fdad-e51430700260@yandex.ru> <27a58fb2-d2ee-e5fc-158d-ec41be401987@yandex.ru> <83y3l0za1f.fsf@gnu.org> <259c557d-e3a3-c01b-9ba3-30df09d247ea@yandex.ru> <83inc3znpu.fsf@gnu.org> <98f4f0c3-6815-bf86-fa23-1a330c60b9f3@yandex.ru> <87lggwkuth.fsf@tromey.com> <877esgqdhk.fsf@tromey.com> <1fad0c79-cd65-df83-9dcc-2650fed4dad1@yandex.ru> <76696ae3-318c-bb83-bbf9-a4f8680114ba@yandex.ru> <87lggsnkwc.fsf@tromey.com> <854cd0fd-5e4f-771a-0f58-b94373a2f98c@yandex.ru> <878tcgaqd9.fsf@tromey.com> <22dbecf2-4153-9410-722f-e98e48481302@yandex.ru> <83372f8ix9.fsf@gnu.org> <651fd4fb-bd0b-1cf5-62e0-aa8abe104817@yandex.ru> <83eflx7vw2.fsf@gnu.org> <2acd2301-771d-1749-36b7-a08fa6d668e8@yandex.ru> <83d11h7a54.fsf@gnu.org> <2d15ac14-586f-b997-1cce-0e8a6f998584@yandex.ru> <87lgg4wkr6.fsf@tromey.com> 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 1518170076 590 195.159.176.226 (9 Feb 2018 09:54:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 09:54:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 09 10:54:32 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 1ek5O1-0008CT-Ej for ged-emacs-devel@m.gmane.org; Fri, 09 Feb 2018 10:54:30 +0100 Original-Received: from localhost ([::1]:54984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek5Q2-00045j-Mj for ged-emacs-devel@m.gmane.org; Fri, 09 Feb 2018 04:56:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek5Bd-0007ui-T4 for emacs-devel@gnu.org; Fri, 09 Feb 2018 04:41:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ek5BZ-0004C2-TN for emacs-devel@gnu.org; Fri, 09 Feb 2018 04:41:41 -0500 Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:33759) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ek5BZ-0004Aq-Kw; Fri, 09 Feb 2018 04:41:37 -0500 Original-Received: by mail-lf0-x232.google.com with SMTP id t139so10369689lff.0; Fri, 09 Feb 2018 01:41:37 -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=vyweSNxvpy27BS9orRTjkBWLqTidls2RiIpWWb4cz4w=; b=JOdASGrFRmh7dCLX8mPTfefkLS7mj3nFLazIEXb1FMCduCxxZVODD8Tn0x7jdOl2TM 0hUlIsNENpZwQeJtT19Cuu78T21LUoItocQ4VrB8RPLJrvkQKjQO1xgygp6B3wVckqqe 66O5UJJJGmwAFeCtc1qzjE9o78te4nJlSrDBgnlUTo3Qp+mMlr8JY31NGduVkkratM+y 5zPLzVdgGYITlNxWW/ZugsP7o0mOCt3YMZLv3XORUfZpETNhzv8tcg/uu+go4HkwecII UPgt9CRpCsl92FlTwUcdtWY6mb+e12FkgHQaLVLqXXoHTv6yi3ASH3wwMD4GEu26qJMX um8A== 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=vyweSNxvpy27BS9orRTjkBWLqTidls2RiIpWWb4cz4w=; b=odj/F2tj2WCFD/EUr3HPk0XhGcOeEhwlHIV5GtsrNVCK4mOrILGFfKeGU8jZkDmSku fdmnxuEy6ZazR6uATkCNgTEPjuYK+KomvV5VzVCLqFQAOxJQrZFFJ6Fsnew6lew4gGRM /5dCVtoFg+73sZD6sJdHVWvOyYReOu6zh4Qh/aKoHeUBIf9AhyrQ3Ljrpc/ybtE2f6yZ gJq2loDWdhIMNdStbl9Po8cjcwXwGzd4yjfZYoTJor8huDPP+oByKURTXqRO1XcegsId R6XJDFXuMDuUux7vVI0ZOBrXCT/iZcRjyRh7LTMhYYByKOSYjzozw0bGljNF+0gvaSCU f6oQ== X-Gm-Message-State: APf1xPBzqwXnMXpANzM7Dt4juQkKVS+IybAB2ICdP1bRogP3h9zEdEgV bN0JprKLVuuYA9l9uyo6lxmSlvP5 X-Google-Smtp-Source: AH8x225TpZsfHvphjv9KYFCYHWgx6p3f+4ECpE1VQlxLVkKo0Dn552urHjhevM7HWqVwnBC6O7yAQA== X-Received: by 10.25.28.82 with SMTP id c79mr1436932lfc.44.1518169295852; Fri, 09 Feb 2018 01:41:35 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id p83sm377094lfg.41.2018.02.09.01.41.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 01:41:34 -0800 (PST) In-Reply-To: <87lgg4wkr6.fsf@tromey.com> 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::232 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:222634 Archived-At: On 2/8/18 00:30, Tom Tromey wrote: > Dmitry> Maybe with a new option (e.g. 'etags -u --prune'), because it'll > Dmitry> likely take some time. I wonder how much the overhead is going to be. > > One idea would be to detect this situation at M-. time -- that is, when > TAGS tells us about a file that doesn't exist, ignore the bad result and > re-run etags --prune or whatever. You mean call file-exists-p on all files in TAGS before each lookup? That would work. We also have the false positives returned from tags-completion-at-point-function to deal with. I was thinking of using e.g. inotify when it's available, but have not decided on the fallbacks. > The reason I added --find was to circumvent both this problem (though as > you saw, I didn't actually write this part) But which problem exactly? As we recall, 'etags --find' turned out to be somewhat slower than 'find ... | etags'. > and also to deal with a > couple other problems: the need to avoid Makefiles (gcc and gdb have to > be built out-of-tree, which is a pain for running "make tags"), and > consequently the need to have the config be accessible to etags itself. I think, to a certain extent, we can get the same separation of information using the '--regex=@regexfile' and standardizing on a file name for that. But this won't help recreate the multiple TAGS files structure with inclusions. As a smaller step forward, maybe 'make tags' will call 'etags --prune' when a certain environment var is set.