At 04:36 PM 5/10/00 +0300, [EMAIL PROTECTED] wrote:
>Paul,
>
>thanks for your immediate help first, it now works, but:
>
>> [...]
>
>> >> To verify this, look at the first line of each project
>> >> file. It should read
>> >>
>> >> (jde-set-project-name "UNIQUE_NAME")
>>
>> Should be
>>
>> (setq jde-project-name "UNIQUE NAME")
Oops, I should have checked. My first email was correct, I guess.
Anyway, I've been thinking about the problem of prj.el files and I think
I've come up with a solution that will avoid the need for context-switching
and will at the same time make the prj.el file framework more user-friendly.
The solution is the following:
1) Make all JDE variables customizable (as they are presently).
This allows users to use customize to set JDE variables.
2) Make all jde variables buffer local.
Buffer local means that each buffer has its own independetly set
copy of each jde variable.
3) Loading a project file updates the local copies of JDE variables.
This differs from the current scheme where loading the prj.el file
updates the global variables. Interesting, it is how prj.el files
originally worked, before the Emacs customization feature became
available.
Steps 2 and 3 eliminate the need to do project context-switching
to ensure that the variables are always set right for the current
buffer.
However, what happens when a user modifies the value of a variable,
using customize? The problem is that customize modifies the value
of the global instance of a variable, not the buffer local instance.
The current context-switching scheme offers one solution.
The next step provides another, superior solution.
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.
This scheme preserves the benefits (no context switching, automatic
inheritance of global values) of the original JDE prj.el file design, which
used buffer local variables, plus the ability to use customize to set the
variables, which was not part of the original scheme.
I should have done something like this from the beginning. The problem is I
was not familiar enough with customize to know how to hook the customize
set function. After a couple of years of experience tinkering with
customize, I now realize that it is fairly straightforward to implement
this scheme.
What do you think?
- Paul
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.
