Re: Per-language project-search-path, was: Re: Unified project interface

[Dmitry Gutov <dgutov@yandex.ru>]

On 08/01/2015 01:43 PM, Stephen Leake wrote:

> My experience is always with a project file; the user explicitly selects
> which project file is active. That can be multi-language or
> single-language.
>
> So I'm not familiar with the project system trying to guess a project on
> the fly, as the current code does.

I'm not discussing a particular project backend here, just the API. And 
you can use the user-selected backend everywhere, if there's an 
appropriate element at the head of project-find-functions.

If I recall, you've mentioned a concept of project file listing 
different search-paths for different languages. Without 
project-search-path taking the language into account, you'll have to 
append all paths together.

And what about jdee? Would you treat lisp/.dir-locals.el as the project 
file for Elisp, and ask the user to select it?

> As you point out, there are use cases for using the major mode to
> influence the project, and others for not doing that.

I've only listed the implementation difficulties. If there are any 
particular problems with the concept of dispatching on the language, I'd 
like to hear about those.

> I don't know which would be better as the default; the only general
> solution is to require a project file.

How does that translate to API requirements?

> Ede also uses the (require 'path/file) style; not surprising, since it
> was written by the CEDET team.

It does. This doesn't seem relevant.

> I don't see any implementations of ede-source-paths, and only one use of
> it, so it's hard to say what the purpose of the mode parameter is.

That's true, unfortunately. The only implementations I could find are in 
malabar-mode (another third-party project attempting to provide a Java 
editing environment).

Eric, could you tell if we're missing anything? Are there other places 
where ede-source-paths is defined or used?

Any reason why symref isn't using it?