On Tue, Aug 31, 1999 at 04:33:27PM -0400, Paul Kinnucan wrote:
>
> Action Customized Variables*
> ------------------------------------------
> Open A [a b c]
> Open B a [b c d]
> Switch to A [a b c] d
>
> * brackes indicate which variables are updated when the buffer
> is activated.
>
> After just three steps the customized variables equals the union
> of the sets of variables customized by each project individually.
well, the way i see it, JDE reloads the project file everytime we switch
to the buffer...or something like that.
but anyways, if it does so, why don't you make the JDE variable
buffer-local ?
open A, set a,b,c to be buffer local. then open B set b,c,d to be buffer
local. you don't have to bother about that problem.
when you open two files of project A however, then they could 'share'
the same variables. you could make something like a group-local set of
variables... project-local ?
they would not need the buffer-local stuff.
load a file from project A and just keep those variables in a hash which
has the project for key. or a tree which has projects for nodes.
make just that tree non-local, and access all the variables of the
project through the tree instead of through their name.
now if you want to customize them in your .emacs, they woyuld get
resolved last, but if they are customized for a project, they would
resolve first if you're in that project.
only the tree global, all variables project-local.
> In my original implementation of prj.el files, I had in fact saved only
> customized variables in the prj.el file but soon discovered this problem.
> I realized that when updating the global variables to reflect a project
> switch, I had to update ALL the variables. I had to set the variables
> customized by the project to the customized variables and all other
> variables to their standard values. So that's why prj.el files work the way
> they do. At the time, I was in a hurry to get the prj.el feature out and
> resetting all the JDE variables seemed good enough.
project-local is the way to go if we can figure out something clever
about it.
or is there something such as 'multiple-buffer-local' or
'group-of-buffer-local' in elisp ?
>
> Now, however, I'm prepared to revisit this issue. I can think of way to
> make this work, for example, when updating variables, I could go through
> all the JDE variables and mark those that were customized by the current
> project. Variables customized by other open projects would be reset to
> their default values. However, before doing this, I'd be interested in why
> people think saving only customized variables is a good idea.
>
> I should also note that I am toying with the idea of having project
> hierarchies where subprojects could inherit or override the settings of
> parent projects or even those in the .emacs file. The way this would works
> is fairly simple, the JDE would apply all the prj.el files found in the
> current projects directory tree. Settings found lower down in the tree
> would shadow settings higher in the tree (override capability).
take a look at the way the attributes are stored in the document model
of swing.
it has a tree very similar to what you want.
resolve from leaf to root if not found.
>
> - Paul
>
>
>
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
