Re: RE: Ignore_Beep doesn't

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Thu, 21 Mar 2002 08:32:17 -0000 wrote Nick Tatham <nick.tatham@xxxxxxxxx>:

> I don't like editing jed.rc any more as it means I must merge changes on
> every Jed upgrade. I prefer to use defaults.sl and I believe that is the
> official preferred way to customise now anyway (is this true?). Defaults.sl
> starts empty so there are no merge problems.

To find out what happens when jed starts up, read the (pretty old)
documentation in jed.tex and (as this does not tell anything about
defaults.sl) the comments in site.sl. The core of this reduces to (if I am
right): 

  On startup jed loads
     site.sl
     defaults.sl
     ~/.jedrc or (if this file does not exist) jed.rc

Settings in one file will overwrite the settings in a previous loaded file.

Now we are ready to answer the questions:

> Q2: Why can't I set IGNORE_BEEP in defaults.sl

Your .jedrc or jed.rc sets IGNORE_BEEP and thus overwrites your change in
defaults.sl.

> Q1: What is the preferred way to customise?

I use defaults.sl just for changes in site.sl, i.e. to add some things
(e.g. my home-lib code and bugfixes)

From .jedrc, I call a file gm.sl where I do all my settings.

On Unix, you could also copy your private settings from defaults.sl to
~/.jedrc (which will not be overwritten when upgrading), unfortunately this
will not work under DOS and successors.

Feature request:

could we have a more clear naming convention for the startup files?

site.sl     is no longer a site-wide configuration file but provides basic 
            jed functionality via Slang library functions. A name like
            "libfuns.sl" or "basic.sl" would (IMHO) be more telling.
        
defaults.sl could then be renamed to site.sl, 'couse this is what it is -
            site-wide extensions/modifications to the standard
            functions/settings

jed.rc      should become just a template, with a name telling this (like
            "template.rc" (finding telling names that fit into the 8.3
            scheme is a really hard thing - suggestions welcome) and
            that is *not* read in when no ~/.jedrc exists. 
            
            This way the user on a single-user OS that cannot copy jed.rc to
            .jedrc will not get his/her changes overwritten with every release.

            Once we are at changing names, we could also to rename the
            private configuration file that resides in the standard jed
            library to rc.sl (to make clear that it is a slang file)
                        
Then:

  A system administrator can place the site-wide configuration into
  Jed_Library_Dir/site.sl (which not included in the jed distribution by
  default (as is now defaults.sl)).
  
  A single-system user could use Jed_Library_Dir/site.sl or
  Jed_Library_Dir/rc.sl for the private settings (without fear of
  overwriting the changes by the next release).
  
  On Unix systems, the normal user can (optionally) use file ~/.jedrc to
  modify the default and (if any) site-wide settings.
  
  The "template.rc" file tells the sysadmin/user which options for
  configuration exist (and the standard defaults for these) but 
     - will not be read in at jed startup
     - does not overwrite a file that is read in on startup.


In my opinion, this would improve the transparency of jed's behaviour - what
is yours?

Guenter

--
G.Milde@xxxxxxxxxxxxxxxxxxxx


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