emacs-devel
[Top][All Lists]
Advanced

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

Re: running EDE from a file that is not under a project root dir


From: Stephen Leake
Subject: Re: running EDE from a file that is not under a project root dir
Date: Thu, 06 Aug 2015 10:03:03 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)

Eric Ludlam <address@hidden> writes:

> On 08/06/2015 04:37 AM, Stephen Leake wrote:
>> For example, if you are in an Ada file that is not part of the current
>> project, and invoke 'ada-find-other-file' (to move from body to
>> specification), you will get an error "file is not in the current
>> project". That prevents the sort of error you describe above.
>>
>> But all commands that use project information should get it from the
>> single current project, yes.
>
> Ah, this is the distinction I was missing.  The global project only
> affects unaffiliated files.  I think I could agree with that.

Only a few project-related commands work from files that are not part of
any project; xref-find-identifier would be one of the ones that does.

In files that are part of a project, it is still the single global
project that is used.

>> There are two levels of "optional" here; `ede-current-project' could
>> always check the global var first; people who don't want that style just
>> leave it set to nil.
>>
>> Or the single global variable could be one of a user-configurable list
>> of things that ede-current-project checks.
>
> The logic I would expect is that the buffer local variable wins, and
> if it is empty, it checks the global project.  That would prevent
> mistakes and provide flexibility.  If you want the global value to win
> against the local value, that could be an option which I would avoid
> using. ;)

As long as I can avoid having the buffer local variable ever get set,
that would work for me. From the little I've seen, that seems like major
surgery on the current EDE project-detect code.

> I tend to work across multiple projects at the same time because CEDET
> is a support library, so I test it with different other projects.
> Having to constantly select what is active would be a PITA for me.

Ok, that's a good use case. Hence the Emacs Prime Directive :).

>> Hmm. In addition, I would expect the Development | Load Project menu
>> command to set the global variable, but others won't. So that needs to
>> be configurable somehow. Ah; if ede-current-project is set to not check
>> the global variable, it doesn't matter if it gets set. That was easy :).
>
> The load menu just makes sure the project has been loaded in, then you
> can use project browsers and such.  Selecting the active project seems
> like a different feature.  

It could be a separate menu item, as long as they are both clearly
visible at the same time. 

So "load project" would add the project to the list of projects that
"select project" offers.

> I'd want to see the suite of options before
> recommending what goes where.

Right; the devil is in the details.

-- 
-- Stephe



reply via email to

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