[Top][All Lists]

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

Re: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-f

From: Dmitry Gutov
Subject: Re: Project support and completions (Was: Re: bug#19466: 25.0.50; xref-find-def doesn't find C functions)
Date: Sun, 25 Jan 2015 01:25:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

On 01/25/2015 12:26 AM, Eli Zaretskii wrote:

For example, it sounds to me that by having an "add project" and
"remove project" commands, we can give the user the ability to tell

A specific project solution could provide those commands.

which projects' databases of symbols are relevant to what she is doing
now.  Then Emacs can select completion candidates from the list of
projects currently in the active set.

This introduces a new constraint on the potential "project" API. While we want to be able to list files or buffers (and maybe do something with their contents) from all current projects, there are commands in Projectile that necessarily work just on one directory, such as:

- Visit project in Dired.
- Run a build tool, ag, grep, or any plain shell command in root.
- Run vc-dir in root.
- (Might or might not also fit the description) Regenerate tags.

So the project API either has to be able to designate one project as the "main one" while implementing "list all files" differently, or dynamically look up the real current project root, to use in those commands.

Such a paradigm will not
overwhelm users, since knowing which packages one is working on at any
given time is something we all do anyway.

I believe some would still prefer just having it inferred.

Ideally, the popular extensions should already be there.  Working on
several packages at the same time is not an uncommon use case.

If the projects are unrelated, personally I'd rather keep them separate.

Or, in the example you've given before (application and a library it uses), at least with certain languages/environments the project solution could automatically infer all the libraries used by the current application, as well as their current sources, from the project file. That would make add-project and remove-project commands unnecessary, leaving only select-project.

reply via email to

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