>>>>> "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. 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. Cheers Phil
