Re: [SPAM UNSURE] Re: Unified project interface

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/08/2015 04:35 AM, Stephen Leake wrote:

> Yes, that's the point. That's how you distinuish between multi-language
> and single-language searches.

That is inadequate. An ideal "project" implementation should be smart 
enough to figure out whether to look for the symbol's definition in the 
files with the same extension as the current one, or in files with some 
other extensions as well.

Elisp is lucky to have all its environment at hand. In many cases, for 
decent "find definitions" result, we'll need to know the project 
structure first anyway.

>> I think that there should be just one backend there, set in
>> a minor mode, that knows enough about this mixed project's structure,
>> to know where to search.
>
> I don't see how that would be better; that minor mode would end up doing
> what I'm suggesting the "project" code do.

Maybe. Why wouldn't that be better?

> I don't have a working example of this precise structure now. What I'm
> imagining is a "project file" that lists source directories without
> regard to language. To be concrete, imagine a project with the following
> structure:

That looks decent, but if you mean that xref-source-directories would 
take the whole set of source directories defined for that project and 
only take those from it that correspond to the current language, that 
seems unnecessarily limiting to me (unless there's a way it can be very 
smart about that, and the notion of "current language" will be 
generalized to possibly mean an arbitrary set of major modes and file 
extensions).

Further, I don't want to have xref-source-directories as a separate 
variable or a function, unless we have to.

The idea is to add a new feature to Emacs that deals with projects, and 
make xref use *that*.