[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Mon, 27 Jul 2015 16:00:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 07/26/2015 09:57 PM, Stephen Leake wrote:

Then it's not "global", is it? It's "operate on this set of projects,
exclude that set". So you need a way to specify sets of projects.

Maybe the "global" is not the right word, but I'm quite confident that if I ask an average user what a "search across project" action should do, it would replace in the current project, (maybe) in the included ones, and definitely not in the installed libraries. Even if they're writable.

Even if we add a "choose which projects to touch" interface, it's good to have a reasonable default.

But according to you, the "search path" will be just the directories
inside the project's tree, right?

No, I have been explicitly saying that is not the case; the search path
is whatever the project file says it is.

Sorry, I've replied to that part before reading the rest, and then forgot about it.

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?

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.

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.

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?

No. We should have project-root for tools that need a root directory.
xref-find-regexp needs a search path, not a root directory.

It could include the root directory in the search path, if it's not already there. But it seems you don't want to do that. Okay.

xref-find-regexp searches project-search-path. project-search-path is
set by reading the project files. The project files are provided by the
user. Voila, xref-find-regexp does _exactly_ what the user wants, no
more, no less.

Very well.

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.

Further, the system search path should be separate, because it's usually specified like that in project files already, in my experience.

And if someone were to create, say, an ECB panel showing the current project layout, they might appreciate having the information about these directories being different.

If you (or someone else) don't like using "project search path" for the system libraries path, feel free to suggest another name.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]