Re: Re: jed extensions and startup file names

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Sat, 6 Apr 2002 01:18:24 +0200 wrote Klaus Schmid <klaus.schmid@xxxxxx>:
> From: "Guenter Milde" <G.Milde@xxxxxxxxxxxxxxxxxxxx>
 

About my initialization scripts
-------------------------------

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

1. When make_ini produces an annotated ini.sl file, it assumes some pretty 
   standard conventions:

   * custom variables are defined via the custom_variable function, at the
     beginning of a line.
     
     (the relevant code is as simple as:
          % list custom variables (assuming the definition starts at bol)
          if (Make_ini_Verbose)
            while (bol_fsearch("custom_variable"))
              {
                        push_mark_eol();
                        str += "% " + bufsubstr() + "\n";
              }
          bob;
      )
     
   * Module documentation  is at the top of the file
   
   * Funktion documentation precedes the function (not implemented yet)


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

2. I would like one user-library directory that is set automatically by jed.
   When home-dir initializes a jed home directory, it assumes that this
   directory is structured similar to JED_HOME, i.e.
     - the library is Jed_Home_Dir/lib
     - the online doc (made from the tm-source)
       is under doc/txt/libfuns.txt


Extension packages and modules
------------------------------

> >     gm2/ is a subdir of your library, right?
> 
> No, it may be located anywhere.

Then you'd need the full path in the evalfile/require command, e.g.
   require("mini-help", "/home/milde/.jed/lib/gm2/mini-help.sl"),
vs.
   require("mini-help", "gm2/mini-help.sl"),
with automatic user library setting.      


> 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 ???)


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

You are right, to work with multifile modules, the scheme needs to be
extended.

Currently, most of my packages are only one file. If a file depends
on other scripts, this is normally a more general feature or utility that is
shared by many modules.  (Exceptions: Help files, latexcfg.sl.) 
These are now accessible without any need for settings in .jedrc/jed.rc.

OTHOH: a more complex/complete package could also gain from my
initialization scripts:

1. Producing of the jdcini.sl file (or just jdc/ini.sl):
   One could enhance/extend make_ini so it inserts the
   autoload commands preceded by a path, e.g.
   
   autoload( "sl_tab_completion", dircat( path_dirname( JDCINI), "sltabc.sl"));

   Then, going to jdc/ and doing make_ini would give you a start for the
   ini.sl file.
   

2. Declaration of the module:

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

   How about 
      full_filename = expand_jedlib_file("filename");
   
   and
   
      variable package_dir = path_basename(expand_jedlib_file("filename");
      
   (Requires the filename to be known but normally it will be known and is
   less likely to change than the path.) 

 
   With that, and my home-dir script activation would reduce to one line:

     require( "jdc/jdcini.sl");
 
   (assuming, jdc/ is a subdir of the Jed_Home_Library).


A variable for jed.rc 
---------------------

> a variable
> for jed.rc (or however called) and maybe a menu item
> 'edit config file' would be nice to have in this context.

A minimal change in site.sl would make this possible:

--- site.sl        Mon Apr  8 11:32:38 2002
+++ ../stdlib/site.sl        Wed Oct 10 13:46:29 2001
@@ -2781,10 +2781,10 @@
 }
 
 % This is the command line hook function that is called from main
-variable init_file;  % make the init_file public for further reference
 define command_line_hook () %{{{
 {
    variable n, i, file, depth, next_file, tmp;
+   variable init_file;
 
    n = __argc; --n; i = 1;               %  skip argv[0]
    if (BATCH) 

However, the remake of the whole command_line_hook is one of the topics of
this thread...

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