From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Matzi Kratzi" Newsgroups: gmane.emacs.devel Subject: Please make etags path-aware Date: Sun, 3 Feb 2008 22:39:31 +0100 Message-ID: <7f9b11c90802031339v4dd79fas96bbf6b28b0ded15@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1202074793 20921 80.91.229.12 (3 Feb 2008 21:39:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Feb 2008 21:39:53 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 03 22:40:14 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JLmZL-0006Oj-1N for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 22:40:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLmYt-0002QG-1J for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 16:39:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JLmYp-0002Q7-Lm for emacs-devel@gnu.org; Sun, 03 Feb 2008 16:39:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JLmYn-0002Pr-EC for emacs-devel@gnu.org; Sun, 03 Feb 2008 16:39:34 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLmYn-0002Po-3v for emacs-devel@gnu.org; Sun, 03 Feb 2008 16:39:33 -0500 Original-Received: from wx-out-0506.google.com ([66.249.82.229]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JLmYm-0008Fp-Nl for emacs-devel@gnu.org; Sun, 03 Feb 2008 16:39:32 -0500 Original-Received: by wx-out-0506.google.com with SMTP id s7so1682476wxc.24 for ; Sun, 03 Feb 2008 13:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=abl1x48XeDEIp0eV0xMDCRpTg5b2FGQG2lCIw0Wgd7k=; b=APqCl7iUJiATwaXj8NycY9lCeWxnJRL2OmIf3qUCNkHKppyQhAvVI+6GHXH2o9ElvkwdkoUbnqhfIcz4xf4nde7B6vZfoRhhjaQvrhiyRTQxSR4InzO24rgb0FSQZCOhbSfzpd99rQixTpnW6kK2WfZPn8sq8HsL/CpotjDeIKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=etb2Q6bH9U2YBM2qtaGQyn81XVdu9gjo21ZJcz+8u2DLmHgv94pehjNU6V8A3ut77m7f+HkAvAv4s080DK0Ryn1N1ENCSTgBBcI0KwzRze/m/ZTpc2aukhvn7CIglFNVM1gDr3/V2amRFWotfhIcTbo7ZEWG8SCbNp4yINrykl0= Original-Received: by 10.150.49.15 with SMTP id w15mr2587369ybw.32.1202074771735; Sun, 03 Feb 2008 13:39:31 -0800 (PST) Original-Received: by 10.150.154.21 with HTTP; Sun, 3 Feb 2008 13:39:31 -0800 (PST) Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:88114 Archived-At: I maintain multiple versions of the same SW and I have always multiple revisions from different branches of the same files loaded simultaneously in the same emacs. etags is wonderful, but I have to remember to visit-tags-table every time my focus switches. Couldn't emacs do this for me? All my sw are located like this k:\src\Produkt1_release1 k:\src\Produkt1_release2 k:\src\Produkt1_release3 k:\src\Prudukt2_release1 It would be nice if you somehow could connect a src-path to a tags-path: c:\tags\Produkt1_release1\TAGS c:\tags\Produkt1_release2\TAGS c:\tags\Produkt1_release3\TAGS c:\tags\Prudukt2_release1\TAGS "k:\src" could then be a variable as well as "c:\tags". Some would probably choose to use the same value for these to variables. Anyhow; tags-verify-table checks that the table has not been updated since loading it. Couldn't that function be made to check for a logically "better" TAGS?