Re: RE: Ignore_Beep doesn't

["ks" <klaus.schmid@xxxxxx>]

----- Original Message -----
From: "Charl P. Botha" <c.p.botha@xxxxxxxxxxxxxx>
To: <jed-users@xxxxxxxxxxx>
Sent: Friday, March 29, 2002 7:03 PM
Subject: Re: RE: Ignore_Beep doesn't


> On Fri, Mar 29, 2002 at 05:39:18PM -0000, Nick Tatham wrote:
> > What I don't want to do is to edit an existing file (eg jed.rc, site.sl

You really don't need to.

> > etc). I want to have a user customisation file that starts empty. Then I
can
> > keep my bits separate from the Jed bits which will make upgrades easier.

If you define your environment variable, jed treats the customization file
delivered with each jed version (jed\lib\jed.rc) as empty, i.e. jed will
only
evaluate the jed.rc to which your environment variable (e.g. HOME) is
pointing to.

Example: using WinXP, Jed09915, wjed.
Prepare jed.bat
  set JED_ROOT=C:\jed
  set HOME=C:\jed_home
  start c:\jed\bin\wjed.exe %1
and put it into your SendTo folder.
Place your customization file jed.rc into c:\jed_home.

Now only your jed.rc will be evaluated. Any other jed.rc's
at any other places, included those, coming with new releases
will be disregarded -- treated as empty or non-existent.

Does this work for you?

Considering this, I would like to modify my proposal for
renaming/reorganizing
the config-files a bit: putting jedini.sl (prior jed.rc or .jedrc) and
jedsys.sl
(prior defaults.sl or jed.conf) directly into JED_ROOT seems more useful
than putting them into JED_ROOT/lib, because this way no one must touch the
lib-files.

For example the present (default) configuration like

IGNORE_BEEP = 3; % Beep terminal during error messages---
                        %  1 == sound only, 2 = visible bell only, 3 = both

could then be modified to

%IGNORE_BEEP = 2; % Beep terminal during error messages---
                        %  1 == sound only, 2 = visible bell only, 3 = both
(default)

Supposed IGNORE_BEEP = 3 is then defined in jedlib (prior site.sl) -- and
there
is no system-manager, who has predefined another value in jedsys.sl.

This way no performance drawback at startup will happen by sequentially
configuring in jedlib.sl, jedsys.sl and jedini.sl. On the other hand a user
who
wants to use his jedini.sl on different systems may prefer to explicitly
overload
all configurations to avoid any conflicts due to different preferences of
different
system managers, thus maintaining his very own and 'big' jedini.sl.

> Has defaults.sl been mentioned yet?  This starts empty.  In fact, it's not
> even distributed with JED, but site.sl checks for it right at the end.

I think this was already described by Guenter: jed.rc/.jedrc will be
evaluated
by a hook AFTER default.sl. One would have to erase/delete jed.rc/.jedrc
with each upgrade to make this work... and copy defaults.sl each time,
because
it gets searched only in JED_ROOT\lib...

> On Debian (not pertinent here, but interesting), we have a jed.conf in
/etc
> (which gets called by site.sl if there's no defaults.sl) that calls .sl
> files in /etc/jed-init.d/.  In this way, one can drop "modules" in
> /etc/jed-init.d/ that get executed by JED at startup, but are persistent
> over JED upgrades.

Could you post jed.conf and a short description of these modules?


> --
> charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
>
> --------------------------
> To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
> the word "unsubscribe" in the message body.
> Need help? Email <jed-users-owner@xxxxxxxxxxx>.
>
>


--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.