> Folks,
>
> > > #jde_filesystem_root_dir# in the directory that the user wants to be
> > > considered the root directory of the mounted filesystem.
> > The JDE prj file
> > > searching mechanism could then be modified to stop its
> > upwards search if it
> > > finds this file.
> > >
> > > What do you think?
> > >
> > > - Paul
> >
> > It looks like this kind of workaround is necessary. It might
> > be cleaner
> > if you added a variable to the prj.el file that could be set
> > to t to mark the
> > root project file rather than introduce an external file. Then you
> > can include it in your customization settings.
>
> I was suggesting a similar thing some time ago. Basically it will
> be function something along the lines of (jde-load-outer-project-file).
> Then user could call this function from anywhere (i.e. at the begining,
> at the end, in the middle) of a project file. This
> is somewhat like being able to call super.method() anyhere from the
> overridden method. It is more flexible that way.
>
> The customize could support an option where user gets to choose where
> the call to (jde-load-outer-project-file) is generated in the prj.el.
> The choices could be at-the-begining (default for
> backword compatibility), at-the-end, explicit.
> When the user chooses explicit then it is the user's responsibility
> to insert the call in the prj.el file whereever they wish.
>
> Does it make sense ?
It has a severe backwards compatability problem. All prj.el files
everywhere except those that are at the root of project trees would have
to have an explicit (jde-load-outer-project-file). The alternatives only
require those jde users who are running on networked Windows machines do
something.
The rest of the world is unaffected.
>
> Last time the suggestion got ignored.... ;)
>
> Sandip V. Chitale 150, Almaden Blvd
> work: (408) 535 1791 ext: 791 San Jose, CA, USA
> email: [EMAIL PROTECTED] 8th floor, Cube 831
> web: http://L064-5440.blazesoft.com
Dave F
