Re: Unified project interface

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07/26/2015 09:57 PM, Stephen Leake wrote:
>
>> A list of project names. Depending on the project manager, that implies
>> a list of project files in one syntax or another, each of which
>> specifies a set of project directories (explicitly or implicitly).
>
> Could you give an example?

Ada, gradle.

> Since they're referred only by names, this sounds like a list of
> dependencies on the installed packages. Those we usually don't want to
> edit, and I'd classify them as system includes.

I don't know who this "we" is, but I usually structure a large project
as a main with several lower level libraries, all of which I maintain,
and I edit them all together to implement new functionality in main. So
that has to be a choice.

>> Trust what the project file says. The user told Emacs to use the project
>> file; it should not try to be smarter.
>
> So, xref-find-regexp won't call project-root. Got it.

Actually, 'xref-find-regexp' should be named 'project-find-regexp' (or
prj-find-regexp). Keep 'xref' for strictly cross-reference stuff;
'project' is for more general project stuff.

Either that, or drop 'project' and just call it all 'xref'.

>> If the user wants documentation in the project, then it is in the
>> project file. If the project manager tool is brain-dead and can't handle
>> documentation, the the user can switch tools.
>
> In that case, will the user add the documentation directory to the
> search-path section of the project file?

Yes, except most backend project files don't have things called
"search-path", since they are not for editors; it would be
"source-path".

> To sum up, I see a strong case for project-search-path as you
> described it (maybe under a different name; like project-directories,
> as it is now), and so far, no real case for project-root.

Ok, we are converging.

-- 
-- Stephe