Phillip Lord writes: > >>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes: > > >> 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. > >> > > Paul> Yes, this problem occurred to me after my previous post. The > Paul> problem is worse because it can lead to corruption of project > Paul> files. Suppose you have projects A and B open. Now suppose you > Paul> customize variable X that still has its default value in both > Paul> projects in a project A buffer and save A's project file. At > Paul> this point, the list of dirty variables has still not been > Paul> updated. Now, suppose you switch to project B and customize > Paul> variable Y and save the project file. Now both X and Y will be > Paul> stored in B's project file though you intended X to have its > Paul> default value in project B. > > Paul> The only solution to this problem that I can see is to provide > Paul> a custom-set function for JDEE variables that updates the > Paul> dirty variable list whenever the user customizes a variable > Paul> during a session. Since the custom-set function is also > Paul> invoked by the defcustom macro to set the variable s default > Paul> value, the JDEE's custom-set function would have to detect > Paul> that it is being invoked by a defcustom macro and not update > Paul> the dirty variable list. This change will require adding the > Paul> set function to every defcustom form in the JDEE code base but > Paul> is probably worth it. > > > I thought about this solution. It has the minor disadvantage that it > will not work for non JDE variables that use the JDE namespace to > piggy back into the project file mechanism. I seem to remember having > used this in the past when I wrote JDE add-on packages. > > I think that there is a simpler solution though. Either modify the > function that generates the project file to add all of the variables > that its saved to the dirty-list. Or alternatively modify the > "save-project-file" functionality to immediately > load-project-file which will have the same effect.
I thought of this and discarded it because it works only if the user saves a customization in the project file. > > Alternatively you could just write a "defjdecustom" macro to add the > functionality to defcustom. Lars Unspellable does something similar in > Gnus with his deffoo macro. > I'll probably go this route, which Eric Ludlam suggested as well. Paul
