Re: startup file names (was: Ignore_Beep doesn't...)

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

----- Original Message -----
From: "Guenter Milde" <G.Milde@xxxxxxxxxxxxxxxxxxxx>
To: <jed-users@xxxxxxxxxxx>
Sent: Thursday, April 04, 2002 1:29 PM
Subject: Re: Re: Re: startup file names (was: Ignore_Beep doesn't...)


> ich schreibe die ausführlichen Kommentare mal lieber in einer privaten
mehl,

Let us continue in forum, I'll try to be short ;)

> IMO, templates are a kind of documentation - I would look for them there.
> Also, they would/should show up in the Help>Browse_Docs menu. (BTW, why is
> changes.txt not in the doc/ subdirectory?)

IMO changes.txt is a meta doc like readme or install. You may implement them
all into jed menu the same way as the doc files.

> I'd like it the other way round: 2 pointers to the directories (with
> sensible defaults)
>
>    Setting up a directory for extensions is something I believe should be
>    done by default, not triggered (or even worse programmed) in a
>    configuration file.
>
>    I'd offer 3 instead of 2 environment variables (additional:
JED_RC_FILE)
>    but gain more flexibility and transparency. In most cases, not all of
>    them will be needed.
>
>    Giving directory pointers is IMO more straightforward than to explain
>    the user: If you set the variable JED_RC_FILE, its path is also taken
as
>    your JED_HOME
>
>    The defaults for Jed_Site_Dir and Jed_User_Dir can still be changed in
>    the config file (but will be used for finding the config file in the
>    first place)
>

Not sure what your target is: names of jed config files or a convention
how to implement jed extensions. The latter seems much more difficult
or even impossible to organize. A user might install, try and use different
extensions, written by different authors, different updates, same function
names, ...
all in parallel -- not in time scope but locally. IMO there can be no
superseded
instance but the user to handle this. All we can do is to make the install
and
remove sequence of an extension package as easy and safe as possible.

Or would you like to collect permanently all new extension packages and
install a
debian-like package management?

IMO the most would be done, if an extension package would
be designed to ease installation and removing:

- unzip a package to a folder of my choice, e.g. gm2
- insert one line in my jed.rc (or do it at the slang prompt)
  evalfile( "gm2/gmini.sl");
- avoid heavy startup loading,
   i.e. 'light' content of gmini.sl:
     autoload( "help", this_path()+"help.sl");
     autoload( "help_sub", this_path()+"help_sub.sl");
     ...
     % description of commands included in the package...
     % proposal to bind some commands to keys...
     % proposal to define some custom variables...
     % ....

- removing temporarily just by commenting out in jed.rc:
  % evalfile( "gm2/gmini.sl");

Regarding the naming of jed config files, I just wondered why Unix needs to
'cook his own soup' compared to windows and vax.

In conclusion I am afraid (just in a realistic sense) there is no much room
to make things easier for less experienced users.

Klaus


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