At 09:54 AM 3/15/01 +0100,  [EMAIL PROTECTED], wrote:
>Would this new project feature allow for any degree of separation (or
>overloading) of more general and more specific settings?  If I correctly
>understand the current system, the jde first loads the customizations
>specified in .emacs (or other customization file) then it tries to find a
>project file, called prj.el, in a parent directory of the current file.  The
>first project file is then loaded.  But is it possible to have multiple
>prj.el files, where say the first would reside in /projects, the second in
>/projects/project1, which all get loaded (and where the second project file
>is more specific and overloads the first, which in turn overloads the
>customizations)?

My standard answer to this question, which comes up frequently, has been
no, because I could not think of a way of implementing it that would not
break project context-switching. However, in composing my reply to you, a
method finall occurred to me that I think might work. The algorithm starts
when a user opens a Java file or switches to a buffer that is in a
different project from the current buffer  (detected by comparing the paths
of the project file in the current buffer with the project file in the
destination buffer).

1. Reset all JDE variables to their default values.

2. Reset variables customized in the .emacs file to their .emacs values.

3. Successively load all the project files in the directory tree of the
current buffer,
   starting with the topmost project file in the tree and proceeding downward.

Each prj.el file would set only the variables that it wants to override.
This is different from the current implementation where the prj.el file
sets all the variables.

The result of this approach is that the lowest prj.el file would override
the one above it, which would override the one above it, etc, and the
topmost would override the settings in your .emacs file. Put another way,
you could use your .emacs file to specify options that apply to all
projects and then override them with specific prj.el files.

Do you seen any problems with this algorithm? Any improvements?

- Paul

Reply via email to