Re: jed extensions and startup file names

["Klaus Schmid" <klaus.schmid@xxxxxx>]

----- Original Message -----
From: "Guenter Milde" <G.Milde@xxxxxxxxxxxxxxxxxxxx>
To: <jed-users@xxxxxxxxxxx>
Sent: Friday, April 05, 2002 1:02 PM
Subject: jed extensions and startup file names

> This is, why I want a default directory for a user-library that is
> prepended to the jed library path (if existent).

I assume you would like all user-library files in _one_ directory.

> No. All I want is:
>   + Have ~/.jed/lib prepended to the jed library path.
> And then I can
>   + Have some subdirectories there (that are not in the library path)
>        contribs/    % for stuff downloaded somewhere
>        projects/    % for stuff that still needs debugging or is stalled
>   + Use make_ini.sl to create a file ini.sl that has autoload commands for
>      the functions defined in my library (but not in the subdirs).
>   + evaluate this ini.sl from my .jedrc

I.e. you want to store foreign packages in contribs and own packages
in project. I assume a package may be only one file, mutliple files
or a complete directory branch. To activate a package you want to
copy all files from the container directory to the library directory.

(file name conflicts when using some packages in
parallel, packages with subdirs, undo the copying ???)

>     gm2/ is a subdir of your library, right?

No, it may be located anywhere.

>   As long as this are only proposals, ok. I dislike modules that mess in
>   my bindings.

So do I.

>   This is, why my make_ini.sl puts comments about custom variables in
>   the produced ini.sl (if in verbose mode)

I assume you suppose that any jed extension must follow some
conventions about comments or doc files to work in this system.

> My scheme is: after a test phase with require("gm2/gmini.sl") I move the
> script to the library and do M-x update_ini. Removing can be done by
> moving to a subdirectory again and updating the ini.sl.

No problem if a package is only one file, otherwise I would not assume
all users are happy with searching, copying and moving files just to install
or remove some jed extensions.

IMHO the drop-in feature and automatic autoload generation could be
very nice for a) jed extensions consisting of a single file b) user macro's
written from scratch.

e.g. for an IMHO very easy implementation of an jed extension with
several files (.sl, .txt,...).

Activation in jed.rc:

variable JDCINI= "xyz/jdc/jdcini.sl";
()= evalfile( JDCINI);


Content of jdcini.sl (shortened):

autoload( "jdc", dircat( path_dirname( JDCINI), "jdc.sl"));
add_completion( "jdc");
public define jdce(){ ()= find_file( dircat( path_dirname( JDCINI),
"jdc.sl"));}
add_completion( "jdce");
autoload( "sl_tab_completion", dircat( path_dirname( JDCINI), "sltabc.sl"));
#iffalse
% blabla ... template for jed.rc
define global_mode_hook (hook_name)
{
   if ( hook_name == "slang_mode_hook")
     {
 set_buffer_hook( "indent_hook", "sl_tab_completion");
     }
}
#endif

I hope the concept and it's advantage gets clear:
the package jdc is a directory called jdc with several files.
It may be located anywhere. The actual location has to be
defined only once by definition of JDCINI. All functions in
the package can refer to other package files through JDCINI.
No modification of jed_library_path required.
Minimum file handling required: unzip to directory, remove
directory. Not yet realized, but IMO todo: a list of all global
names so the user can check against already existent names.

A nice jed feature (next release?) would be a function like

  File= this_file();

from which a slang file could retrieve it's own complete filename.

With that, activation would reduce to one line:

()= evalfile( "xyz/jdc/jdcini.sl");

or just loading by hand and M-x evalbuffer().

And -- as already requested some posts ago -- a variable
for jed.rc (or however called) and maybe a menu item
'edit config file' would be nice to have in this context.

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>.