From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Etags.el (was: UI inconveniences with M-.) Date: Tue, 28 Apr 2015 23:12:53 -0400 Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83pp6pwqnw.fsf@gnu.org> <553EB74A.4030208@yandex.ru> <83618gwbb1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430277201 14910 80.91.229.3 (29 Apr 2015 03:13:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 03:13:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 29 05:13:12 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnIQr-0006io-QR for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 05:13:06 +0200 Original-Received: from localhost ([::1]:36618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnIQq-0006X2-S2 for ged-emacs-devel@m.gmane.org; Tue, 28 Apr 2015 23:13:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnIQn-0006UX-HG for emacs-devel@gnu.org; Tue, 28 Apr 2015 23:13:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnIQm-0006Ha-M9 for emacs-devel@gnu.org; Tue, 28 Apr 2015 23:13:01 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:33344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnIQh-0006GQ-5O; Tue, 28 Apr 2015 23:12:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMQPxIUGA0kiBOiEYwBGgoCPQwDgz4Dg3AEo2OEWA X-IPAS-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMQPxIUGA0kiBOiEYwBGgoCPQwDgz4Dg3AEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117738006" Original-Received: from 184-175-14-21.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 23:12:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 73BDD4650; Tue, 28 Apr 2015 23:12:53 -0400 (EDT) In-Reply-To: <83618gwbb1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Apr 2015 17:57:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185992 Archived-At: [ Moving this to emacs-devel. ] >> I really think the etags backend should only return data when the TAGS >> file is in one of the parents of the current directory. > That goes back to the "working on several projects" discussion of > yore. Specifically, you might be working on two related packages > (e.g., one calls the other) that live in two different directories. And as mentioned back then, this would be solved by providing a way for the user to tell etags.el about the link between those two projects. For the case where this link only exists during the running session, we could simply use the existing "visit-tags-table" functionality where you can add a TAGS file to the one(s) already loaded, so the new functionality would behave similarly to the old one. >> And it should also be able to keep several independent TAGS tables >> opened for different projects in different directory trees. > It already does that. No it doesn't. It lets you use the union of a set of TAGS tables, which means that the TAGS tables of independent projects pollute each other. Stefan