At 03:41 PM 5/10/00 +0000, you wrote:
>
>Paul Kinnucan <[EMAIL PROTECTED]> wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>> 3) Replace the generic customize set variable function with a JDE version
>> that sets the local as well as global instance of the variable.
>>
>> This function would popup a menu that would list the currently open
>> projects and All Projects. If you select All Projects, the function
>> will update all buffer local instances of the global jde variable.
>> If you select a particular project, it will update only the buffer
>> local instances of the project you specify. In both cases, the
>> function will save the value in the prj.el file automatically,
>> avoiding the current two step process needed to save project-specific
>> values of the variable.
>
>I like everything else about this proposal except the idea of saving to
>prj.el automatically - what if I want to just make make temporary changes to
>values for the duration of the session? Maybe your function should work
>differently if the user selects "Set for current session" as opposed to
>"Save for future sessions" from within customize?
>
>>
>> P.S. This is an interim solution. My long range plan is to replace or
>> supplement the prj.el file with a new, more sophisticated plan.
>
>Have you looked at the EDE that was written by the speedbar author
Yes.
>(http://www.ultranet.com/~zappo/ede.shtml)? It looks like it could evolve
>to be a pretty good project management browser
>
My concern is that it is C and makefile oriented and not easily adaptable
to the Java development model. I want something that is as easy and
intuitive to use as Visual C++'s project management system, not something
that requires you to handcraft make files. My view is that it's okay for a
development system to use makefiles internally (as Visual C++ does) but the
development system should generate the makefiles automatically, not require
the user to do so. The development system should be able to use makefiles
created by users but it should not require users to create makefiles. My
problem with EDE at the moment is that it does not abstract far enough away
from the traditional Unix, makefile-based development model. Essentially
EDE is a thin lisp wrapper around a makefile. You can't really create a
project without a fairly good knowledge of makefiles and makefile terminology.
Eric Ludlam, EDE's author, is well aware of my concerns. We work for the
same company in the same building and have had many discussions about the
EDE. We have agreed to work together to try to develop a Java project
management system based on EDE. My role would be to develop a prototype to
see what, if any, additional generic features EDE needs to accommodate
Java. Eric would then implement the additional core EDE features while I
would implement the Java specific extensions.
The ultimate goal would be to turn EDE into a true multilanguage project
management system that would allow you to create a project with, say, a C
component, a Java component, and even an Emacs Lisp component, and then
build the whole thing with a single command.
- Paul
------------------------------------------------------------
TECH SUPPORT POLICY
I respond only to requests that contain a complete problem report. The
easiest way to ensure that your report is complete is to include the output
of the JDE->Help->Submit Problem Report command in your request.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JDE website: http://sunsite.auc.dk/jde/
JDE mailing list archive:
http://www.mail-archive.com/[email protected]/maillist.html
