Phillip Lord writes: > >>>>> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes: > > > >> 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. > > Paul> I thought of this and discarded it because it works only if > Paul> the user saves a customization in the project file. > > True enough. I guess that your scenario is more destructive than the > current behaviour (where the user just looses their customisation on > moving to project B). > > >> > >> 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. > >> > > Paul> I'll probably go this route, which Eric Ludlam suggested as > Paul> well. > > > This will also make it easy for third parties to piggy back into the > JDE project system I think, without having to use the "jde-" namespace > which the system currently depends on. > > I'd be quite happy to give this a go if you'd like. Might take a day > or two (it's pub night tonight!). >
Okay. Your assignment, should you choose to accept it, is to create a macro named defjdeoption. It should do everything that defcustom does plus store a customized variable on the dirty variables list and offer the user the option to save a customization to the current project file. Paul > You loose the nice fontification of "defcustom" in the lisp > though. Ain't there always something! > > Cheers > > Phil
