At 02:42 PM 11/11/00 -0600, you wrote:
>I think there is a third "level" needed, in both the new configuration
>scheme Paul is creating, and the changes Nic is doing to the current.
>
>The three "levels" of configuration needs form a hierarchy/inheritance:
> 1) Global: Base default configuration all projects start with, including
>across all users. Overrides JDE defaults.
>
> 2) Package: Per package/project settings. Overrides anything in Global.
>
> 3) Environment: Local user specific things for the machine's environment.
>Overrides anything in Package.
>
>Only overrides are specified at each level, not everything is in each like
>today's prj.el. (tangent: an enhancement idea I have desired but not looked
>into yet is to simply have a customize list of JDE variables to not save in
>prj.el, so that JDE config info updates to per machine special elisp files
>aren't also needing repeated updating in the prj.el files).
>
I tried what you are suggesting about two years ago, when I was first
updating the prj.el system to handle customized variables. In fact, my
first implementation did exactly what you are suggesting. I soon discovered
that partial prj.el files work fine if you never open more than one project
during a session. However, if you do open more than one project, the
settings of all the projects become intermixed as the partial prj.el files,
with overlapping but nonidentical variable subsets, get loaded. Neither I
nor the other people who discussed this issue could figure out, given the
need for project context-switching, a way to have each prj.el not set ALL
the JDE variables.
I posted a detailed analysis of this problem in the list at the time.
Perhaps you can find it in the archive.
To reiterate, I do not think the prj.el system is a suitable foundation for
the kinds of things you want to do. I'm sure that you can, to some extent,
hack it to do what you want but I believe the end result will be fragile
and difficult to understand and use. That is why I prefer to build another
system designed from the beginning to support the kinds of features that
teams of developers need.
- Paul
