Re: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 29 Jan 2015 16:19:19 -0500
> From: John Yates <john@yates-sheets.org>
> Cc: Brief Busters <dgutov@yandex.ru>, Emacs developers <emacs-devel@gnu.org>
> 
> EZ> For example, it sounds to me that by having an "add project" and
> EZ> "remove project" commands, we can give the user the ability to tell
> 
> JY> Such a model is inherently stateful, hence problematic. It makes 
> JY> multiplexing work on multiple projects difficult and error-prone.
> 
> EZ> Stateful, yes. Working on a certain project or a set of projects is
> EZ> indeed inherently stateful.
> EZ>
> EZ> I don't see the problematic part in that, though. Could you elaborate
> EZ> on what practical problems you see with this?
> 
> Eli,
> 
> To me your proposed model of "add project" / "remove project" seemed
> just too reminiscent of etag's paradigm for managing tag tables.

There's nothing inherently wrong with that, is there?

> Of late I have been using git-new-workspace. In that setting
> find-tag forever seems to open the _wrong_ file. More perniciously
> it often opens one that looks right though in a different workspace,
> thereby slowing me down and making me paranoid.

I never used git-new-workspace, so I don't really understand what you
describe here.  In any case, this sounds like a problem with the
program that created the TAGS file, not with find-tag per se: the
latter just obeys what's in the database.

And I'd still want to know what are the problems with the stateful
approach I proposed.