Re: progmodes/project.el and search paths

[Stephen Leake]

Nix <address@hidden> writes:

> On 3 Aug 2015, Stephen Leake told this:
>> I prefer to cache it in a global variable; that way, I have only one
>> project active at a time, for all buffers.
>
> That doesn't work very well for those of us working on multi-component
> projects. 

Fine; of course this behavior should be user-configurable.

At the same time, I work on multi-component projects all the time, and
one active project works for me.

> If I'm working in the Linux kernel I do *not* want identifier
> search or file lookup wandering into glibc or Emacs, even though they
> share some identifiers (with completely divergent definitions) and even
> though I may have quite a lot of buffers open on those projects.

> (I have fairly often worked on things that affect glibc, binutils, GCC,
> and the kernel all at once. Those are different projects with distinct
> roots, identifier sets, and tags tables...)

But if you are in glibc, looking at an identifier for a function that
happens to be defined in the linux kernel, you want to be able to find
the corresponding definition; the linux kernel is a subproject of glibc
(which is a subproject of higher level projects like Emacs). 

So the Emacs project tools should reflect that. For example, file name
completion must handle duplicate file names. That's a problem right now
in Emacs for elisp files; there are both lisp/cedet/ede/dired.el and
lisp/dired.el in Emacs core. 'load' and 'require' handle this by having
only lisp/cedet in load-path, not lisp/cedet/ede. So if I do file name
completion with just load-path, I have to know to type ede/d<tab> when
searching for ede/dired.el, which is _not_ friendly. But if I do file
name completion with an expanded load path that includes cedet/ede, it
shows only one dired.el (it happens to be ede/dired.el). Which is also
not friendly; I'll be filing a bug report on this later today.

For identifier search, you can use a cross reference tool that
understands name overloading; AdaCore asistant is one - it uses cross
reference information output by the compiler, which obviously handles
the duplicate names correctly. 

The multi-component projects I work on are in Ada, using the AdaCore
tools. Both make multi-component projects easier to work with, and Emacs
Ada mode understands the full project structure. Recently we added a
large C++ component to one product, and it suffered from some of the
above problems. So part of the solution is using a better programming
language (not always a choice, but it will never happen if we don't ask
for it!).

In addition, sometimes the user wants to search all subprojects,
sometimes a subset. So we need a good way of specifying subsets of
subprojects at search time. Emacs Ada mode doesn't support this yet (I
just put up with the unwanted hits in searches; better than false
negaitives). Hardcoding the searchable subset to only the top-level
project is overly restrictive.

-- 
-- Stephe