Phillip Lord writes: > >>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes: > > > >> Basically as far as I can see the JDE variables which are liable > >> to be different from the default values are those which have been > >> set at some point. Otherwise they will have the default values > >> right? > >> > > > Paul> Hi Phil, > > Paul> I can't see any problems with your change and it really speeds > Paul> up project switching. I added your code with a few minor > Paul> changes (one to fix a small bug) to the JDEE sources. Thanks > Paul> for providing this improvement. > > Paul> Paul > > > > Paul > > I have thought of one occasion when this will work differently from as > now. Possibly better, possibly worse. > > If you have just set a variable using customise, but not saved it, and > then you switch projects, it will not get reset to its default. I > think this is unlikely to be a problem. If you are working on two > projects, and you customise a variable you generally save it straight > away. Otherwise it gets reset as soon as you change project. I'm not > sure this new behaviour is any better or worse than before therefore. >
Yes, this problem occurred to me after my previous post. The problem is worse because it can lead to corruption of project files. Suppose you have projects A and B open. Now suppose you customize variable X that still has its default value in both projects in a project A buffer and save A's project file. At this point, the list of dirty variables has still not been updated. Now, suppose you switch to project B and customize variable Y and save the project file. Now both X and Y will be stored in B's project file though you intended X to have its default value in project B. The only solution to this problem that I can see is to provide a custom-set function for JDEE variables that updates the dirty variable list whenever the user customizes a variable during a session. Since the custom-set function is also invoked by the defcustom macro to set the variable s default value, the JDEE's custom-set function would have to detect that it is being invoked by a defcustom macro and not update the dirty variable list. This change will require adding the set function to every defcustom form in the JDEE code base but is probably worth it. Paul
