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

[Stephen Leake]

Eric Ludlam <address@hidden> writes:

> On 08/05/2015 02:43 AM, Stephen Leake wrote:
>>> >I find the global project concept scary.  I can't say how many times
>>> >I've edited Emacs code that was wasn't on my load path because I had
>>> >multiple checkouts of the same code.  Mostly just too many times.
>> You misunderstand my point. I don't want a project that includes all
>> files on the disk (which is what I think you are refering to); I want a
>> single project that is active in all buffers.
>>
>> Most other IDEs I've used have the notion of a single active project;
>> the splash screen asks for the project to open.
>>
>> That's how Emacs Ada mode works; the user selects the single active
>> project. They can later select another one.
>
> I have used IDEs with "global" projects, and I consider Emacs an IDE
> with a single global project for "emacs lisp" code (among other
> things, of course. :) It has handy functions like 'find-function' and
> 'find-library' that lets you move to definitions and files.

I use Emacs as an IDE for all kinds of things, not just elisp. I assume
you do as well; that's what EDE does, after all.

> The reason I don't like global projects is that if you are in one
> resource (for Emacs any old .el, .txt, etc) and call `find-function',
> it will jump off to the code, but unless you pay attention, you might
> end up somewhere you don't expect.  For example, if I have two
> versions of my source code open, such as ede.el in Emacs vs ede.el in
> CEDET's repository, and I blindly jump from a symbol, I'll could end
> up in the wrong place based on what my load path is.

I find that an odd definition of "wrong". Since you know 'find-function'
searches load-path, why would you expect to go somewhere that is not on
load-path?

I guess you mean something like "I forget to change load-path when I
switch to thinking about a different project".

That makes sense; Emacs does not provide a menu for a set of load-path
settings.

That's one thing an elisp project backend should do; similar to setting
the source file path for a gcc project. There should be a menu of
possible projects to choose from, so it becomes easy to change
load-path.

Of course, since Emacs doesn't support unloading things, you can't take
this very far; at some point, you have to quit and restart Emacs. But
then the menu can still be there to choose what project to work on.

> In my mind, all files should be deterministically bound to a project
> so when you perform an operation, you always know where you're going.

Many files are in core sub-projects that reused in higher-level
projects; most Emacs code uses window.el and other core files, some
Emacs code uses ELPA libraries; all C code uses the C
standard library, some C code uses many other libraries.

So I don't see how you can definitively determine the search path from
looking at a single file.

In addition, just because I'm in an Ada file doesn't mean I want to
search for other Ada files; sometimes I do, sometimes I don't.

That's _exactly_ why I prefer a single globally active project that I
explicitly select; then I know what the search path is, no matter what
file I'm in.

And when I decide to start thinking about a different project, I tell
Emacs that by selecting that project from the menu. Then Emacs _knows_
what I'm thinking about; it doesn't have to guess.

> Some files are "in" projects. In your case, a way to associate a notes
> file outside a project to a project sounds important.
>
> Having a 'global' project could be useful if you only ever edit one
> project at a time in a given emacs instance, 

Yes.

> and you want everything
> to behave as if it were.  

Were what?

If you mean "Emacs should treat all files on the disk as if they were
part of the current project", then no.

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.

> I don't picture most Emacs users operating
> like that.  

I have no idea who "most Emacs users" are, or how they use it. I do know
a few users, and they use it like I do (mostly because I taught them :).

I have heard complaints that "emacs is not like other IDEs". So when I
see _every_ other IDE providing a single global project, it seems
obvious that Emacs should support that as well.

> If it is feature to be added, it should be optional.

Of course; that is the Emacs Prime Directive :).

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.

I haven't read the ede code carefully enough yet to say which might be
better.

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 :).

-- 
-- Stephe