I find the current location of project files convenient but moving them
to a central location wouldn't bother me much. I like Rich John's
suggested method for determing project file locations.
However, I don't want to _have_ to use multiple frames for multiple
projects. I work in several different projects at the same time
frequently (almost always) and sometimes only have a console available -
and rarely want multiple emacs frames up anway.
I think it would be confusing to view A in several different frames but
it only use A's project in one of them... so compilation args, etc. for
A depends on which buffer I'm viewing. And would a project be restricted
to one frame? Some folks may use many windows.
In general, having this as a mode seems fine... requiring it feels too
restrictive. How about a single option where you set 'frame-based'
projects or not? Then maybe using the new debugger implies a switch to
the'frame-based' projects if there is no other option for setting
projects correctly?
john
Paul Kinnucan wrote:
>
> Hi All,
>
> I am thinking of revising the way projects work in the JDE to put each
> project in its own frame. The motivation for doing this is that it would
> solve a lot of headaches associated with the current way of maintaining a
> project's properties. Currently, every time you switch source buffers, the
> JDE determines which project the buffer belongs to and reloads the project
> file for that buffer, thereby setting all the JDE variables to the values
> specific to that project. This can have disconcerting effects when stepping
> through a program. For example, suppose you step into the JDK source, which
> has no project associated with it. When you step into source for which
> there is no project, the JDE sets the JDE variables to those in your .emacs
> file. Thus, when you step into the JDK, the jde-db-source-directories
> variable, which is used by the debugger to find source files, gets reset to
> the .emacs file setting or to the default setting which is "". The bottom
> line is that stepping into source belonging to another project (or no
> project) can cause the debugger to lose its way.
>
> To solve this problem, I propose that we associate each open project with a
> separate frame. The title bar for the frame would contain the project's
> name. Instead of resetting the project variables every time you load a
> source file or switch buffers, the JDE would reset the variables only when
> you selected the frame. Thus, suppose you Project A and Project B open and
> were currently working in Project A (i.e., Project A's frame has the input
> focus). The following table contrasts the differences between the current
> project handling and the proposed handling for a typical sequence of
> user actions:
>
> JDE Action
> User Action Current Proposed
> -----------------------------------------------------------------------
> Open A source file in A No action No action
> Open B source file in A Load B's prj.el* No action
> Switch frames from A to B None Loads B's prj.el
> Open A source file in B Load A's prj.el No action
> Open B source file in B No action No Action
>
> * Loading a prj.el file causes the values of JDE customization variables,
> e.g, jde-global-classpath, to be reset to those specific for the project.
>
> The net effect is that settings of JDE variables are local to
> project frames not to source buffers. This means that you can open
> another project's source file in the current project's frame without
> triggering an update to the new project's variables. This is very
> convenient for debugging (stepping causes the JDE to open source
> files automatically).
>
> I think it's also is advantageous from a UI point of view. It allows
> you to know immediately what project you are working in at all times.
>
> I'd like to hear your feedback on this proposal.
>
> - Paul
