[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Etags.el (was: UI inconveniences with M-.)

From: Eli Zaretskii
Subject: Re: Etags.el (was: UI inconveniences with M-.)
Date: Wed, 29 Apr 2015 18:52:32 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 28 Apr 2015 23:12:53 -0400
> >> 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 as mentioned back then, until something like this is coded, this
discussion is just theoretical.

> >> 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.

It's an approximation, yes.  Feel free to implement something better;
until then, what we have is quite good IME (I use it every day).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]