At 12:58 AM 3/15/2005, Paul Kinnucan wrote:
Ole Arndt writes: > Hi Lars, > > Lars Degerstedt <[EMAIL PROTECTED]> writes: > Also, I've never understood the big attraction of having to manually find and open a project file, edit it, and then save it, an error-prone and tedious process. Not my idea of a good time but, heck, to each his own.
Why do we use JDEE at all instead of just using the customize interface to make emacs perform like we want to? Because there's no option that turns on all the functionality we want. I generally edit prj.el by using the customize interface, but I'll sometimes edit prj.el directly. There's a few cases where I do this, which probably indicates my wish list of prj.el enhancements.
I'm copying a prj.el file to a new but related project. I want most of the settings to be the same, but there's some points where the project name is hard-coded. M-x replace-string is actually better than jde-customize-variable, because I know I won't skip a variable.
I want to run the program with a different set of arguments, but be able to swap back to the old arguments. Generally, this involves changing the arguments passed to junit.textui.TestRunner from <package>.SmokeTestSuite to <package>.NightlyTestSuite. I copy the old value to a comment, and then (usually) uncomment the value from the last time I did this.
I want to turn on profiling or remote debugging, so I want to comment/uncomment a fairly complex set of arguments and not have to remember how I set them.
Of course, there's always the alternative of proposing a change to the JDEE to enhance the customization interface to support features that you need, e.g., providing the option to specify a function to compute jde-sourcepath or as in this case regular expressions.
This is the better long-term solution, assuming somebody has the time and knowledge to implement the solution.
Troy ---------------------------------------- Troy Daniels [EMAIL PROTECTED] 781-273-3388 x218
